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PREFACE 



This is the first Proceedings of meetings of the Digital Equipment Computer Users Society. Formed in 
March 1961, for the purpose of fostering the interchange of information, ideas, and the advancement of 
the art of programmed data processing - particularly with application to the Digital PDP-1, the Society 
(DECUS) has grown in numbers and in scope. DECUS now maintains a programming library facility for its 
members and issues DECUSCOPE, a technical newsbulletin, every month. 

The papers presented at two Meetings which took place in 1962 are the subject of these Proceedings. A 
one-day Symposium was held May 17, 1962 at ITEK Corporation in Lexington on the subject: "Image 
Processing and Displays." A two-day Annual Meeting, in October 1962, was hosted by the Computation 
and Mathematical Sciences Laboratory, AFCRL, Hanscom Field, Bedford. The papers presented covered 
a wide range of subjects and the meeting was highlighted by a lively Panel Discussion called: MACRO, 
DECAL, and the PDP-1 . Some of the papers given then are still in the germinal state but the authors 
were prevailed upon to contribute them. During 1962, users of a second Programmed Data Processor, the 
PDP-4, were welcomed to DECUS. More will be reported in the 1963 meetings about this data processor. 

The rapid growth of DECUS and its diverse interests are evidenced by the presentations themselves. What 
may not be clearly visible is the remarkable spirit of cooperation in the interchange of such diverse infor- 
mation. The 1962 Proceedings are a testimonial of this cooperative spirit and a tribute to the authors. I 
regret that there was not space forthe sparkling good humor and even wit, which enlivened the discussion 
between papers and during the questioning periods. Every user member was represented and participated 
fully. 

DECUS is deeply grateful to all who have contributed to the substance and embellishment of this first 
endeavor , 



Elsa Newman 
DECUS Secretary 



TABLE OF CONTENTS 

Page 
FOREWORD 

C. M. Walter, President ^ ^ ix 

Section I UTILITY PROGRAMS AND TECHNIQUES 

A PERIPHERAL PROCESSOR FOR LARGE COMPUTERS 

D. T. Monk 3 

TRANSLATION PROBLEMS OF A PERIPHERAL COMPUTER 
IN A MULTI-LINGUAL HOUSE ■ 

R. P. Abbott and L. E. Mish . . . ; 5 

A SYSTEMS TAPE FOR THE PDP-1 

F. Bonnell 7 

TED: A TAPE EDITOR 

C. R. Brown and D. W. Connolly 9 

SCOPETRACE 

J . R. Hayes . . •' 13 

MATRIX PACKAGE FOR THE DX-1 EXPERIMENTAL 
DYNAMIC PROCESSOR AT AFCRL 

C.J. Caso, J. M. Sexton and J.N. Seltzer .;.... 17 

DECAL-BBN 

(BBN Symbolic Version of DECAL) 

R. J. McQuillin 19 

Section II PROBLEM ORIENTED TECHNIQUES 

MINIMAX DETECTION STATION PLACEMENT 

R. D. Smallwood, Lt 23 

USE OF THE PDP-1 IN OPTICAL DESIGN 

M. V. Morello, E.J. Radkowski, M. P. Rimmer and R. R. Shannon 25 

COMPUTER AIDED ANALYSIS OF 
MULTIVARIABLE SYSTEMS USING COLOR SCOPE 

CM. Walter 29 



VII 



A WORLD OCEANOGRAPHIC DATA DISPLAY SYSTEM Page 

E. Fredkin 31 

THE VORTEX OCEAN MODEL 

E. Fredkin * « 33 

SPACE WAR.' 

REAL-TIME CAPABILITY OF THE PDP-1 

J . M. Graetz 37 

ON-LINE PROCESSOR-ORIENTED 

INVESTIGATION OF A CLASS OF DYNAMIC ATTRIBUTE 

EXTRACTION AND CLASSIFICATION PROCESSES 

C. M. Walter 41 



Section III HARDWARE AND INPUT-OUTPUT TECHNIQUES 

FILM READING USING A COMPUTER 

A. M. Cappelietti 55 

A FUNCTIONAL DESCRIPTION OF THE ITEK DISPLAY SYSTEM 

E. W. Pughe, Jr 57 

A TIME-SHARING SYSTEM FOR THE PDP-1 COMPUTER 

J . E . Yates 61 

PROCESS CONTROL APPLICATIONS OF PDP-4 

C. G. Bell 63 

Section IV PANEL DISCUSSION 
DECAL, MACRO AND THE PDP-1 67 

Section V APPENDIX 

ANNUAL MEETING A-1 

ATTENDANCE A-3 

AUTHOR INDEX A-5 



Vlli 



FOREWORD 



These Proceedings comprise a broad spectrum of papers whose color, in a figurative sense, ranges from the 
deep blues of special utility programs and debugging aids, through the lush greens of problem oriented 
techniques, to the rosey hues of new hardware aids designed to enhance the on-line use of computers. In 
organizing the papers we have attempted to portray the typical cycle of events centered about the utili- 
zation of a new class of computers. 

Much initial energy has to be expended on the creation and improvement of utility programs and systems 
before anything very useful can be accomplishedwith oursystems. To those of us who are strictly problem 
oriented, this is an extremely frustrating time, made bearable by the naive hope that it might be brief and 
end with some powerful general problem solving language In our possession. Unfortunately, this dream is 
inevitably dispel led as we proceed to call for a diversity of modes of control, and of action, which strain 
the existing hardware and programming systems to their technological limits, in our quest for useful results. 

From the insight thus gained, however, is created the structure of new programming systems, and of pro- 
cessor configurations better fitted to provide each particular user with assistance in solving the problems 
of interest to him. The onset of the second stage of activity is already clearly discernible from the orien- 
tation of a majority of the papers in these Proceedings. The theme is closer man-machine interaction. 
This theme in present, both in the increased emphasis on on-line programming, debugging and problem 
solvingaidsutilizingscopeand light-pencil communication, and in the requisite improvements in flicker- 
free scopes, time sharing hardware, and optical l-O devices. 

It has been a singular pleasure, during the past two years, to have been in a position to observe the evoJu- 
tion of a Society which spans such a diversity of on-line processor configurations and uses. In this brief 
interval of time the small scale processor has evolved from a meager and inadequate substitute for a large 
central computer, into a formidable device whose flexibility and increasingly lower cost makes it the 
logical candidate for a multitude of real-time information processing operations. 

The ease with which hardware can be tailored to particular applications has already out-stripped the soft- 
ware development problem. However, as the engineering technology rapidly improves, and the ultimate 
user becomes more intimately tied to the operating system, we may look forward to an era in which better 
control can be achieved and maintained over the growing software domain. 

C. M. Walter, 
DECUS President 
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UTILITY PROGRAMS AND TECHNIQUES 



LAWRENCE RADIATION LABORATORY'S PDP-1 
A PERIPHERAL PROCESSOR 
FOR LARGE COMPUTERS* 

Dorothy Monk 



Abstract 

LRL's PDP-1, installed last summer, is now 
in full time operation as a peripheral pro- 
cessor for Livermore's Lore, Stretch, and 
7090s, which are occupied full time with 
scientific computing. 

We will discuss briefly 1) the motivation 
(economic and otherwise) which led to the 
choice of the PDP for this job; 2) general 
considerations which affect the specifica- 
tions o f systems and production programs 
used on a computer for this purpose; 3) some 
of the specific tasks with which our com- 
puter is occupied; 4) advantages and dis- 
advantages observed so far of the PDP in 
this environment; and 5) some implications 
for the design of a peripheral processor of 
PDP class. 



The Editor regrets that the full paper was not re- 
ceived in time to be included in these proceedings. 



TRANSLATION PROBLEMS OF A PERIPHERAL COMPUTER 
IN A MULTI-LINGUAL HOUSE 

R. P. Abbott and L. E. Mish 



Introduction 

Datamation - the oracle of our burgeoning indus- 
try - has mentioned, on more than one occasion , 
that Lawrence Radiation Laboratory is a hodge- 
podge of incompatible machines. This paper might 
be considered, somewhat, as an "Insider's Con- 
fession . " Our present computer configuration con- 
sists of three 7090's, two 140rs, one LARC, one 
STRETCH, one 650, and, of course, one PDP. We 
are in the process of converting the three 7090's 
to two 7094's. In the foreseeable future, the com- 
puter complex will be expanded to include a CDC 
3600, as well as a CDC 6600. These machines 
speak such different languages as Decimal, Bina- 
ry, Concise, BCD-eeze, XS3-eeze, and, of 
course, thet old standby, Hollerith. Frequently, 
the output from one of these machines is needed as 
input to a code which is on some other machine. 
Usually, the two machines do not speak the same 
language or the data must be rearranged or both . 

In addition to the computer complex, there are many 
data gathering devices located at various testing 
stations, both at LRL and at other agencies. These 
devices generally speak one of the aforementioned 
languages, but the dialects include 35 mm photo- 
graphic negatives, 5 or 8 channel paper tape, 
punched cards, and 7 or 8 channel magnetic tape . 
Most of these may be odd parity, even parity, or 
both. Thus, we are called upon to make a trans- 
lation, conversion rearrangement, or both. The 
PDP, to which can be attached enough lO gear to 
be able to accept and generate all of the languages 
and dialects, was programmed to make these trans- 
lations, conversion, etc. 

Programming for the PDP 

Two ground rules were established prior to initiat- 
ing the programming . 

1) Because there are at least two lO devices in- 
volved in each translation code, the processing 
speed of each code should be equal to the max- 
imum rate of the slowest of the involved devices . 

2) Whenever possible, all Input and Output data 



must be checked for validity and parity. 

IBM cards - intermixed Hollerith and binary - to 
IBM magnetic tape 

The translation from intermixed Hollerith and bina- 
ry has been done onour140Ts, but to take advan- 
tage of the faster card reader and for backup rea- 
sons, it was decided to make this available on the 
PDP also. 

Ground rule 1) calls for an examination of rates, 
so-oo. The card reader can run at 2100 cards/min . 
The maximum rate for putting card images on 15KC 
tape is a bout 3750 card images/min . The processing 
rate, by rule 1), shall be 2100 cards/min. Rule 2) 
says that we shall validity check the Hollerith cards. 
The binary cards will be checked by the large com- 
puters at read-in time . Each record on magnetic 
tape shall be checked and "standard tape tech- 
niques" shall be used. "Standard tape technique" 
means that if a bad record is encountered, that rec- 
ord shall be backspaced, a space equal to one record 
gap shall be erased, and the record shall be re- 
written andrechecked . If ten erasure attempts fail 
to yield a good record, the problem shall be re- 
started and the tape replaced . 

The conversion from Hollerith to BCD is not wired 
into the PDP so it must be programmed. The first 
approach took 103 decimal cells and, on the aver- 
age, took 47.6 ms to empty the card reader buffer 
and convert. This was a weighted table search 
where a maximumof 16 searches were made for each 
character. The only trouble with this method was 
that the 47.6 ms is much too large for an individual 
card cycle of 28.4 ms when running at 2100 cards/ 
min. 

The method finally used is a direct table-look up 
using the Hollerith punches as the table address. 
For each character, the punches in rows 1-9 pro- 
vide the table address, and the punches in rows 12, 
1 1 and provide a correction factor . This approach 
empties the buffer and converts in only 10 ms, which 
is well under the required 28.4 ms. Space-wise, 
the fast conversion is a dog. It takes 463 decimal 
cells, of which only 87 contain data or instructions 



and the rest contain zeroes. The zeroes are impor- 
tant to the conversion, however, in that an invalid 
Hollerith punch is converted to one of these zeroes 
and when it is written on the even parity tape, a 
character skip will result and the standard tape 
technique will stop the problem. 

An interesting sidelight is to be found in the time 
versus space analysis in the previous example. 
Speed was increased by a factor of 4,7. On the 
other hand, space was increased by 4.6. This rule 
was found to be true in other examples: That is, 
an increase in speed by a factor of N causes an 
increase in space by the same factor N . 

Now that the code has been debugged and timed, 
it is running at 1600 to 1900 cards/min, instead 
of 2100. This discrepancy seems to be due to the 
summation of plus and minus fudge factors on the 
time quotations for the card reader and tape drive . 
For instance, the card reader time is not a hard 
fast 28.4 ms, but more like 28.4 ±2 ms, under 
ideal conditions . 

Tape start time, and tape stop time, are quoted at 
±1 ms. The fact that the PDP is a 5 microsecond 
machine doesn't begin to dent mechanical delays 
on the order of 5 ms. If a highly integrated tim- 
ing study is made, it might be possible to strike 
2100 cards/min, but is it really worth the effort? 

IBM magnetic tape to LARC magnetic tape 

Another translation problem of interest is the trans- 
lation of IBM magnetic tape to LARC magnetic 
tape, or vice versa. Our PDP has an IBM com- 
patible tape control and a LARC compatible tape 
control . Each control has 2 tape drives. To make 
this a general purpose routine, it was decided that 
the code should stand ready to accept variable 
length records . Rule 2) (validity & parity checks) 
will be satisfied by standard tape techniques. A 
look at rule 1) (timing) provides the brilliant idea 
of simultaneity. That is — let's start one tape 
reading and, at the same time, start the other tape 
writing and perform the translation while theyare 
in motion I It is sort of a "he takes the high road 
and she takes the low road and I'll be in Scotland 
before them." Only, it doesn't work. The com- 
mand structure of the PDP (specifically lackof in- 
dex register) is such that the bookkeeping necessary 
to convert three separate characters from a PDP 
word requires more than 200 microseconds per word 
converted . 



PDP Saves Processing Steps 

The procedure which was finally used is to start the 
read tape, convert the first N words; start the write 
tape, and finish the conversion of the remaining 
words. The processing speed attained with this 
method is about 6 ms longer than the read time. 
This particular translation code isa good Illustration 
of the processingsteps which can be saved with the 
PDP . This code takes output from, say, a 7090 and , 
in one step, produces LARC input. The old method 
consisted of an additional processing pass on the 
7090 to prepare a Hollerith image tape, which was 
punched off line on a 1401 . The cards were then 
converted to a LARC tape by a Remington Rand 
Card-to-tape Converter. 

Other routines 

Other conversion routines on the PDP include: 
Paper tape to magnetic tape, with options to check 
odd or even parity on the paper tape, write odd or 
even parity IBM or Remington Rand tapes. 

Print LARC or IBM tapes on the PDP Printer. 

Magnetic tape to visual CRT, and precision CRT 
with 35 mm camera . This routine handles both 
characters and graphical data . 

35 mm negatives with graphical data to magnetic 
tape. 

IBM tape to IBM tape . 

LARC tape to LARC tape . 

Magnetic tape to printer and magnetic tape to pre - 
cision CRT - simultaneously. 

Our assembly routine deserves mention in that it 
reads the instructions from Hollerith cards, uses 
IBM tape as temporary storage, prints the listing on 
the Anelex printer at 1000 lines/min (the printer 
uses the XS3 language), and the object code is 
punched in binary form on IBM cards. 

Conclusion 

The coding techniques which were finally used in 
our conversion routines are not complex, but they 
do serve to illustrate that one cannot afford to ap- 
proach the trivial problem of data conversions with 
careless contempt. 



A SYSTEMS TAPE FOR THE PDP-1 
Fraser Bonne 1 1 



Abstract 

Routines which are frequently used are stored 
on magnetic tape. In order to use these rou- 
tines, it is sufficient to start the PDP with 
a short paper tape (under TOO words long) 
and then to type four characters which iden- 
tify the desired routine , A loader on the 
systems tape then finds the routine on the 
tape, loads it into memory, and transfers 
control to it. A routine has been written for 
altering the systems tape. 

The Systems Tape 

The systems tape is started by means of a short paper 
tape. The paper tape contains a program which 
finds a loader on the systems tape, loads the loader 
into memory and transfers control to the loader. 
Once the loader is in memory, the systems tape 
may be used simply by starting the computer at a 
specified location . The systems tape loader does 
the following: 

1. Types - TYPE ID. 

2. Reads an ID from the typewriter. (Each 
routine on the systems tape is identified by 
a three -character ID.) The loader will 
accept the last three characters typed be- 
fore a slash (/) is typed. 

3. Searches a table for the ID. (If the IDisnot 
found in the table, the machine will type 

ILLEGAL ID and start again at (1).) 

Gets from the table the number of the record 
in which the desired routine is to be found. 

4. Moves the systems tape to the proper record. 

5. Searches the record for the desired routine 
and reads it into memory. (Several short 
programs mayoccurinthesame record. This 
eliminates unnecessary record gaps.) 

6. Checks for tape reading errors. (If there are 
errors, several attempts are made to read the 
tape. If none are successful, the machine 



will type— TAPE ERROR and then pro- 
ceed as if there were no errors.) 

7. Gets a tape disposition instruction from the 
systems tape. Generally, this instruction 
will be to start the systems tape moving to 
the head of the nearest loader, so that it 
will be in position for the next use. How- 
ever, certain routines called from the systems 
tape will need to use immediately the tape 
control which controls the systems tape . For 
this reason, there is the option of leaving 
the systems tape where it has stopped . 

8. Transfers control to be called routine. The 
systems tape may still be moving to the near- 
est loader. The loader occurs at intervals 
on the systems tape so that no matter what 
position the tape is in, a loader is not far 
away. Optimal placement of loaders has 
not been determined. 

Diagram for Systems Tape Records 
Figure 1 shows a diagram which describes the for- 
mat of a "standard" systems tape record. Provision 
is made for nonstandard records. For example, a 
routine on the systems tape may be divided into two 
parts. The first part may be called in the normal 
manner, while the second partis stored in the next 
systems tape record to be read by the first part at 
a later time . Or, the second part may be read into 
the partof memory which isoccupied by the systems 
tape loader. 

One should have a routine for altering a systems 
tape. One should be able to delete and insert both 
programs and whole records. The routine must make 
the necessary changes in the loader's table of ID's 
and their corresponding record numbers. It should 
be able to read a program from paper tape on other 
media and arrange it in the proper format for storage 
on the system tape. It should see to the placement 
of loaders at specified intervals. (Because certain 
records on a systems tape should not be separated 
by a loader, it is a good idea to use one word in 
each record to indicate whether a loader may im- 
mediately follow that record on the systems tape.) 



FORMATS OF SYSTEMS TAPE RECORDS 



I) Loader: 



Record 
Number 



000000 

(Indicates 

that this 

is a 

loader) 



The address 
of the first 

word of 

the loader's 

table 




(*) 



RN. is the number of the record 
in which is found the routine 
whose ID is ID. . 



Loader's Table 



II) Other Records: 
A) Standard 



Record 
Number 



A positive number means 
advance to nearest 
loader. A negative 
number means backspace 
to nearest loader. 



S-1 , where S is the num- 
ber of records which must 
be skipped to get to the 
nearest loader. (S < 0, 
if next record is loader) 



(*) 



1,1 



"1,1 



(•-1,1 - Fi j) words 
(To be put in 
locations F 



through L 



"1,1 



1,1 



1) 



1,2 



"1,2 



words 



l,k. 



■l,k. 



■l,k^"''l,k^^ 
words 



343536 

(Indicates end 

of program; will 

not be an ID in 

concise code .) 



00 



Systems tape 

disposition . 

(Stop or else 

move to 

nearest loader) 



"Jump 
Address" 



(*) 



2,1 



"2,1 



(*) 



p,kp 



p,kp 



p,kp p,kp 
words 



343536 
(End of 
program) 



Systems tape 
disposition 



"Jump 
Address" 



343536 

(Indicates 

end of 

record) 



000000 

(t) 



000000 

(t) 



(*) I,, ,.., I are the ID's of the P programs contained in the record, 

I P 

(t) The last two words of the record may be used to give information to a routine which alters the systems tape. 



B) Nonstandard 

The first three words of the record must be the same as on a standard record, 



TED: A TAPE EDITOR 
Charles R. Brown and Donald W. Connolly 



Abstract 

The principle and operation of a utility pro- 
gram for the PDP-1 computer are described . 
The program is an aid in the editing or mod- 
ification of alphanumeric text in that the op- 
erator may communicate with the computer 
in the very alphanumerics of the text itself . 
It is a computer time-saver in that the modi- 
fications and the control instructions for their 
accomplishments maybe prepared at an in- 
expensive, off-line machine. 

Introduction 

TED is the OAL program for preparing and editing 
symbolic tapes with the aid of the PDP-1 computer. 
With TED all typing involved in preparing and edit- 
ing tapes may be done at an off-line typewriter 
punch. Thus, TED permits off-line editing in the 
sense that all typing may be done off-line and the 
only on-line time required is that necessary for the 
reading of text and control tapes. 

Editing Features 

With TED tapes are edited by killing a line or block 
of lines, inserting a line orblockof lines, and sub- 
stituting one line for another line. Memory may be 
inspected by requesting one or more lines to be 
typed or displayed on the scope. A line may be 
referred to by its symbolic address. This is true for 
the typing, displaying, reading, punching, killing, 
inserting, and substituting of lines. 

TED has a text mode and a control mode; a mode 
change occurs when an overstrike is typed in or read 
in . When TED is in text mode, characters are stored 
in the temporary text buffer until a carriage return 
occurs. The carriage return resets the temporary 
text buffer and adds the line to the permanent 
buffer. 

In control mode characters are stored in a tempo- 
rary control buffer. A carriage return resets the 
control buffer and causes the control statement to 
be executed. Control statements are not stored in 
a permanent buffer. 



The backspace operates in both modes to kill the 
last character. In control mode it operates on the 
temporary control buffer; in text mode it operates 
on the temporary text buffer. When in control 
mode, the typewriter types in black. Thus, the 
typewriter is in red only when characters are being 
stored in a text buffer. TED starts in control mode, 
black and lower case. 

Control Characters 

Control statements in TED begin with a control 
character that denotes the operation to be perform- 
ed, and operates upon one or more lines of the per- 
manent text buffer. The control characters and 
their general meaning are listed below. 



Character 


Meaning 


t 

. (period) 


type 


, (comma) 


II 


d 


display 


P 


punch 


r 


read 


k 


kill 


. (middle dot) 


II 


/ (slash) 


II 



i insert (after) 

s substitute 

I leader 

Listed below are the eight control statements which 
consist only of a control character. Carriage re- 
turn is indicated by ^ . 

Single Character Statements 



Statemer 


Jt 




Meaning 


t) 






types all lines 


.1 


(period) 


types last line 


A 






types first two lines 


p^ 






punches all lines 


r^^ 






reads all lines 


/^ 






kills all lines 



. ^ (middle dot) kills last line 
1 ^ punches leader 



Control Statements With Symbolic Addresses 
All control characters which are letters (except 1) 
may be used with symbolic addresses; the others may 
not . In TED a symbol ic address is the string of char- 
acters from the carriage return fo the tab. For 
DECAL symbolics, block symbols, program symbols, 
and system symbols would normally be symbolic 
addresses for TED. In the following examples, the 
symbolic addresses are block symbols in the DECAL 
system. ForTED a symbolic address may not contain 
spaces or begin with a period. A control statement 
with one symbolic address is simply the control char- 
acter followed by the symbolic address. An example 
is the "type" statement: 

tstart: I 

which will result in the line with the symbolic ad- 
dress start: being typed. This example is appropri- 
ate for the control characters p, d, and k. The 
control characters r, i, and s require some addi- 
tional explanation. The control statement 

rstart: ), 

will result in the tape being read up to and includ- 
ing the line with the symbolic address start : . The 
control statement 

istart: ), 

will result in the last line of permanent text buffer 
being inserted after the line with the symbolic ad- 
dress start: . The control statement 

sstart: ^ 

will result in the last line of permanent text buffer 
being substituted for the line with the symbolic ad- 
dress start: . This statement is equivalent to 

istart: ^ 
kstart: i 

A line which does not have a symbolic address may 
be referenced by Indicating the number of lines it 
is below a line with a symbolic address. Any line 
with a symbolic address may be chosen. The con- 
trol statement 

tstart :/5 ^ 

will result in the fifth line after start: being typed. 
The count is in octal and should not exceed octal 
77 . The slash is used here rather than plus to avoid 
case shifts. 

The control characters t, d, p, k, and i may be 
used with two symbolic addresses. The format is the 



control character, the first symbolic address, a 
comma, the second symbolic address. The "type" 
example 

tstart:, finish: ^ 

is appropriate for d, p, and k. The first symbolic 
address indicates the first line of a block; the second 
symbolic address indicates the last line of a block. 
Thus, the example would result in the block of lines 
beginning with start: and ending with finish: be- 
ing typed . 

The insert statement has a different meaning. The 
control statement 

istart:, finish : ^ 

would result in the block of lines beginning with 
finish: and ending with the last line of permanent 
text buffer being inserted after start: . 



Special Features 

Whenever TED reads from tape a control statement 
it cannot execute, it does one of two things. (1) 
If the statement begins with a legitimate control 
character the reader stops, the unexecutable state- 
ment is typed, control is turned over to the type- 
writer, and TED goes to control mode. Thus, the 
correct control statement may be typed. (2) If the 
control statement does not begin with a legitimate 
control character it is ignored. Unexecutable con- 
trol statements (beginning with a legitimate con- 
trol character) which are typed in result in "error" 
being typed back. UnexecutoEle statements gener- 
ally occur because a symbolic address was incor- 
rectly typed. 

If TED's permanent text buffer is filled, "buffer 
full" will be typed out in red. If this occurs while 
TED is trying to satisfy a read statement, the read- 
er will stop, control will be turned over to the 
typewriter, and TED will go to control mode. 

If sense switch 5 is up when the buffer is filled, 
TED will punch and kill the first seven lines and 
continue reading, repeating this until the whole 
tape has been read. Thus, TED will read a tape of 
any length. However, control statements should 
not refer to lines which have been read more than 
two or three pages earlier since this much ordinary 
symbolic program material is about the capacity of 
the permanent text buffer . 



10 



TED assumes that a tape begins In text mode . Thus, 
if a tape is to begin with a control statement, the 
tape should begin with an overstrike . When TED 
finishes readinga tape, italways turns control over 
to the typewriter and goes to control mode. 

A display resulting from a statement which is typed 
will be terminated bythe striking of any key except 
space bar. Striking the space bar will cause the 
block being displayed to be indexed . Thus, if lines 
three through five are displayed before the space 
bar is struck, lines four through six will be displayed 
after the space bar is struck. In this manner, the 
display may be stepped through an entire program. 

If a display statement is read from tape, the display 
will be modified by the space bar as described 
above. A carriage return will cause the display to 
terminate and TED to continue reading tape. Typ- 
ing a left paren will turn control over to the type- 
writer and TED will be in control mode. All other 
keys are ignored. 

TED displays both lowercase and uppercase char- 
acters. Thus, a block of lines which is displayed 
will look just as it would if they were typed. The 
only qualification is that the display feature has 
only two fixed tabs. 



Suggestions and Cautions 

In the following, 'f^ indicates uppercase, >l^ 
indicates lowercase, and ^ indicates tab. So 

that the first line of a symbolic tape will always 
have a label, it is suggested that the first line be: 



rTU=^>^ 



If this is done, there will never be a line in a sym- 
bolic tape that cannot be referenced by a label, 
since control statements of the form 



tfrU/ 



are permissable . This procedure will not affect the 
complication with DECAL. 

In order that material typed off-line will look as if 
it had been typed on-line, change ribbon color 
after the overstrike is struck . Tapes should start 
in red. 

If several lines have identical symbolic addresses, 
TED assumes that a control statement with such a 
label refers to the first one. 



If tapes are to be compiled with DECAL, one may 
tab after dss or fin., making these symbolic ad- 
dresses for~TED. 

Before returning the carriage or tabbing, the type- 
writer should a I ways be in lower case. If this is not 
done, TED may not recognize symbolic addresses 
and displayed lines may be in the wrong case. 

TED will read leader and trailer consisting of feed 
holes or "7" holes. Errors made by the operator of 
the off-line typewriter-punch should be corrected 
by backspaces and never by "delete" punches . 

APPENDIX 



Examples of Editing with Ted 

The following subroutine, in symbolic form, with 
hand-noted changes could be edited in a variety 
of specific ways. Two examples are given . 

dss hold mdck ipt < — dss check 

dss cr 

dss prmd black wait 

dss temp cntrl os 

I'pt^ low-O 



rpt' 



rpa 

jsp check 



fin. 

The original symbolic tape is first read into TED by 
striking r ^ . The control tape below is then read 
the same way. 



n 



Off-line control tape; 



Function; 



Example 2; 



rpt'* 
srpt' 

krpt7l,rpt'/5 



_* 
irpt' 

dss check* 

idss 

ddss,a:/15 



rpa 



Text to be substituted 

Control instruction to 
execute same 

Removes lines "c I i" 
through "spi" 
jsp check* Line to be added after 
"rpt" 

Inserts above line after 
"rpt" 

New dss line to be 
added 

Inserts above after first 
dss, which has been 
made a "symbolic 
address" here 

Will cause display of 
entire edited text 

At this point striking a 
carriage return would 
cause the program to 
continue reading the 
control tape. Strik- 
ing the ( would re- 
turn control to the 
operator 

Will make 500 lines of 
feed holes for leader 

Will punch off entire 
edited text 

Will make trailer, as 
above 

Will kill entire text, 
preparatory, for next 
editing job 



Off-line control tape: 



Function: 



dss check* 




Text to b^ inserted 


rpt'* 


rpa'* 




* 


|sp check* 




irpt'/5,fin.'l 




Will insert all three of 
the lines in red (these 
having been added to 
the permanent text 
following fin. which 
here has been made a 
symbolic address by a 
tabafter the period) . 


krpt'/rpt'/5 




Will kill the six lines 
at the top beginning 
with rpt' 


1 




Leader, punchoff and 
trailer as before 



Note; 



The extra carriage returns in the above 
examples are not needed in the actual con- 
trol tape . 



^These symbols print out in red . 
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SCOPETRACE 
John R. Hayes 



Abstract 



A computer program for the Digital Equip- 
ment Corporation PDP-1 computer, but ap- 
plicable in principle to other computers, is 
described. The program is designed to fa- 
cilitate the debugging of object programs 
by providing a geometrical representation of 
the operation of the object program. 



Introduction 

Scopetrace is designed to aid in the process of de- 
bugging programs. Itprovidesa pictorial mapping 
on the scope of the operation of the object pro- 
gram and simultaneously displays the following four 
quantities. 

a. the contents of the accumulator, 

b. the contents of the in-out register, 

c. the address of the instruction being ex- 
ecuted, 

d. the effective instruction, i.e., that in- 
struction which the computer performs 
after indirect addressing and execute 
commands have been taken into account . 



The Scopetrace Display 

Atypical scopetrace display is shown in Figure 1. 
The segment of program traced in Figure 1 is listed 
in Figure 2. In the top row, from left to right,are 
shown the contents of the ac, the contents of the 
io, the address of the instruction just executed , 
and the effective instruction. The addresses being 
traced are shown in the first or left-hand column . 

The firstaddress and all following addresses which 
end in zero are displayed in full. All other ad- 
dresses are indicated by a short horizontal bar. 

The left-hand side of the second column contains 
arrows which indicate the course of the program . 
The arrows are assigned by the following four rules: 



a. When control proceeds from register n-1 
to n and then to n+1, the arrow " ^ " is 
placed next to the address n, i.e., the 
program moves through consecutive in- 
structions. 

b. When control proceeds from n-1 to n to 
some register other than n+1, the arrow 
" — > " is assigned, i.e., the program is 
shown to "jump out." 

c. When control proceeds from some regis- 
ter other than n-1 to n and then to n+1 , 
the arrow " < — " is used, i.e., the pro- 
gram is shown to "jump in." 

d . When control proceeds from some register 
other than n-1 to n to some register other 
than n+1, the arrow " (^ " is assigned, 
i.e., the program is shown to "jump in" 
and then "out" again. 



The right-hand side of the second column shows the 
number of consecutive times that the arrow in the 
left of the column was assigned at the location . 
Whenever an arrow is assigned to a location which 
is different from the last arrow assigned to that lo- 
cation, the pictorial mapping moves over a column . 
Thus, when the sample program jumped out from 
4021 and jumped back in at 4010, the mapping 
moved from column 2 to column 3. Again, when 
the program jumped out at 4020, the mapping moved 
from column 3 to column 4. 



Control of Scopetrace 

The steps outlined below should be followed to ob- 
tain pictorial mapping of a program: 

1 . Read in the Scopetrace tape and start the 
program (Loscopetrace starts at 1, Hiscope- 
trace starts at 5700. 

2. Type in the following four numbers, each 
followed by a space: 
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a. the first address to be displayed. 

b. the last address to be displayed. (Note: 
the difference between the first and last 
address should not be greater than octal 
75 for Loscope trace or octal 64 for Hi- 
scope trace.) 

c. the address at which the object program 
starts. 

d. the memory option, either lOor 30. With 
the 10 option, 6 display columns are a- 
vailabie for pictorial mappingand 10 oc- 
tal words of storage are required per in- 
struction mapped. With the 30 option 22 
display columns are available for mapping 
and 30 octal words of storage are required 
per instruction mapped. The 30 option 
should not be used in Hiscopetrace when 
more than 24 octal instructions are being 
mapped. To do so would cause the pro- 
gram to exceed the available storage . 
When the final space has been typed, the 
addresscolumn will appear on the scope . 



3. Select a "breakpoint," that is, select the 
firstaddressatwhich you want program map- 
ping to pause and put this address in the ad- 
dress portion of the test word. If you want 
the mapping to pause on the nth time it comes 
to the breakpoint rather than the first time , 
then, place n in the instruction part of the 
test word . 



4. Type the letter "b," Scopetrace will halt at 
this point to allow the operator to reset the 
test word . Thus, use of the test word to set 
the breakpoint does not prevent mapping of 
programs which use the test word. 

5. Press continue. The full Scopetrace display 
will now appear. 

The breakpoint may be reset as often as desired. 
Each resetting will allow mapping to continue to 
the new breakpoint. 

Single stepping through the program may be ac- 
complished, after the first breakpoint has been set, 
simply by striking the spacebar. 



The use of breakpoints and single stepping will suf- 
fice for almost all cases. Some cases which cause 
trouble should be mentioned, however. The one 
normal process which requires special treatment is 
typing in. To accomplish a type-in, the following 
steps are necessary: 

a. Set the appropriate breakpoint address in- 
to the test word. 

b. Strike "carriage return." 

c. Strike the character that it is desired to 
type-in. Scopetrace halts at this point 
to allow resetting of the test word. 

d. Press continue. Thiscompletes the type- 
in. 

Scopetrace will not execute an instruction which 
would modify the scopetrace program . Instead trac- 
ing stops before executing such an instruction and 
the mapping of the program up to that point is dis- 
played on the scope. 

An illegal instruction in the object program will 
ha It Scopetrace. Loscopetrace will halt at 502 and 
Hiscopetrace at 6401 . 

Storage Required 

The program plus fixed storage occupies 1077 octal 
registers of memory. Loscopetrace occupies the re- 
gion from 1 to 1 100 and Hiscopetrace, from 5700 to 
6777. The extra storage required depends on the 
number of instructions mapped and on the memory 
option. (See Scopetrace control 2d.). To calcu- 
late the octal number of extra storage registers re- 
quired, simply multiply the number of instructions 
mapped by the memory option. 

Comment 



While Scopetrace was designed primarily as a de- 
begging tool, itisalso useful as an aid in teaching 
programming. Since the accumulator, the input 
-output register, and the effective address are 
displayed, the effects of the various instructions 
may easily be demonstrated. 
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Figure 1 
A TYPICAL SCOPETRACE DISPLAY 
000000 000000 004022 600124 
04005 4- 



04010 



04020 



Ci 



Figure 2 
A TYPE-OUT ROUTINE 



typeword ' 
loop: 



column column column column 
12 3 4 



save: 
count: 
temp: 
oct76: 



dac save 
law' 3 
dac count 
lac save 
cli 
rcl 6 
dac save 
dio temp 
lac temp 
sas oct76 
tyo' 

sp count 
mp loop 
[mp rml 



oct76 
fin. 
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MATRIX PACKAGE FOR THE DX-1 EXPERIMENTAL 
DYNAMIC PROCESSOR AT AFCRL 

Carmine J. Caso, James M. Sexton, Janet N. Seltzer 



Abstract 

Tlie Matrix Package is a system of computer 
programs to perform general Matrix Opera- 
tions . It is centered around an executive rou- 
tine designed to allow effective usage by peo- 
ple with minimal programming experience. 

The Matrix Package breaks down into two parts 
consisting of an Interpreter and Control Portion , 
and an Operation Portion. This sub-division is 
necessitated by the form of the input operation re- 
quest data which is similar to certain Fortran state- 
ments and other problem oriented languages. The 
Interpreter and Control Portion of the system accepts 
the input operation request data, whether it be from 
punched paper tape or from the on-line typewriter, 
and interprets each statement as a specific request. 
In doing so, an operation command table is gen- 
erated and subsequently used by the Control Portion 
in guiding the operation of the stated requests. The 
Operation Portion of the system performs the oper- 
ations as requested by the Control Portion. The 
Operation Portion contains all the necessary rou- 
tines to perform the Matrix Operations as indicated 
by the input request data. 

The Matrix Package operates from magnetic tape 
with the Interpreter and Control Portion being the 
first block. The subsequent tape blocks contain 
the programs of the basic Matrix operations, add , 
subtract, multiply, eigenvalue, eigenvector, in- 
verse, and transpose, and also the necessary input- 
output routines. 

Input-output media may be punched paper tape , 
the on-line typewriter and magnetic tape. 

There are three types of statements for the opera- 
tions request data. The first such statement is the 
Dimension statement. This statement will be used 
to allocate storage locations to the Matrices in- 
volved in the subsequent input request data state- 
ments. All Matrices used must be mentioned here; 
otherwise, an error printout will occur when the 
Interpreter Portion discovers a Matrix name which 



has not been assigned storage area. The Dimen- 
sion statement must be the first statement of the 
input request data. Its format consists of; 1) the 
word SIZE which is a notation to offset this type 
of statement from the others, and to indicate that 
its contents are the Matrices' dimensions: 2) the 
Matrix name, symbol or identification, which must 
be at least one character and no more than three 
characters; and 3) the actual Matrix dimensions en- 
closed by parenthesis and separated by a comma . 
As many Matrices' names as desired may be used 
until storage allocation is exceeded. 

E.G., SIZE A(5,5), BB(20,20), CDE(1,10) 

The CALL Statement 

The second type of operation request data state- 
ment is the CALL statement. This type of state- 
ment is subdivided into two parts, Input/Output, 
and Functional. The input/output statements con- 
tain certain components; a call code, an I/O 
source, and I/O address, a data format, and in 
the case of Magnetic tapes, a block number. The 
call codes are READ, PUNCH, PRINT, WRITE, and 
CALL. The I/O sources are PAPER for paper tape , 
TYPE for the typewriter, and MTAPE for Magnetic 
Tape. The I/O address may be any Matrix name , 
symbol, or identification. The data format spec- 
ifies the type of conversion to be performed be- 
tween the internal machine language and external 
notation. The notations used are I for integer, F 
for fixed point and E for floating point. The num- 
ber of positions of the field which appear to the 
right and left of the decimal point are required 
when using the fixed and floating point data for- 
mat. All Input/Output statements are limited in 
that certain components are legal only with spec- 
ific components. For example, it is correct to 
READ PAPER, READ TYPE, and PUNCH PAPER, 
but is is illegal to PUNCH TYPE, which is also 
somewhat of a difficult task. Punching output on 
the on-line typewriter would be quite a job to per- 
form. Input statements do not require a data for- 
mat whereas Output statements do need a format . 
Magnetic Tape call statements require a block num- 
ber for its data format. 
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OPERATION 

READ PAPER TAPE 

READ ON-LINE TYPEWRITER 

PUNCH PAPER TAPE 

PRINT ON-LINE TYPEWRITER 

WRITE MAGNETIC TAPE (Block 2) 

READ MAGNETIC TAPE (Block 6) 

FORM 



READ PAPER, A, 
READ TYPE, BB, 
PUNCH PAPER, CCE, F3.2 
PRINT TYPE, BB, 14 
WRITE MTAPE, A, B2 
CALLMTAPE, CDE, B6 

Functional Statements 

The functional statements are concerned with the 
calling of a particular Matrix function. These 
statements contain three components; a call code, 
an inputaddress, and an output address. The call 
codes are EVALUE for the Eigenvalue function, 
EVECTOR for the Eigenvector function, INVERSE 
for the Inverse function, and TRANSPOSE for the 
Transpose function. The input and output address 
is the Matrix name, symbol, or identification. An 
example of a functional statement is TRANSPOSE 
ABC, XYZ, which will be interpreted to mean - 
find the Transpose of Matrix ABC and store the re- 
sults in the Matrix area XYZ, 

The Arithmetic Statement 

The third and last type of operation request data 
statement is the Arithmetic statement. This type 
of statement is concerned with three Matrix oper- 
ations; addition, subtraction, and multiplication . 
These statements are made up of the Matrix name , 
symbol, or identification, the storing element, and 
the arithmetic operations. For example, A = BC + 
DEFwhere A, BC, and DEF are Matrix names, the 
literalsdefine the storing element and the plus sign 
is the arithmetic operator. Other operators are the 
minus sign (-) and the multiplication sign (x). The 
Matrix area where the result of the operation is to 
be stored is always to the left of the literals. To 
the right are the Matrix names used in the operation 
along with the desired operator. 

Input Statement 

The media of inputting the source data used by the 
Functional and Arithmetic Statements is determined 
by the Input statements of the operation request 
data. An example would be READ TYPE, ABC, 
which would be interpreted to mean read from the 



on-line typewriter, data input to be stored in the 
Matrix area assigned ABC. Another example, 
READ PAPER, Zl , would mean read inputdata from 
paper tape into the matrix area Zl . 

On-Line Output 

On-line output may be Monitor Information, Error 
Diagnostics and Data Listings. When the Matrix 
Package operation is initiated, a self-explanatory 
message will be printed on-line. This message, de- 
termined by the setting of sense switch 1, will in- 
form the operator as to the media by which the in- 
put operation requests are to be entered. Sense 
switch 1 downsignifies that the input operation re- 
quests will come from paper tape and if it is up, 
that the input operation requests will come from 
the on-line typewriter. 



As the sequence of commands indicated in the input 
operation requests proceeds, a running log of oper- 
ations is printed on-line. The messages may be in- 
formation as to the present operation or they may 
be certain instructions for the operator to follow . 
Monitor information may be omitted by setting 
sense switch ^2. 



Error diagnostics will be printed on-line whenever 
a grammatical or machine error is detected. The 
printout will be a three digit code in red, which 
will represent a specific explanation of the error . 



On-line data listings as requested in the operation 
requests will be listed, headed with the Matrix name 
symbol, or identification. The listing will have a 
maximum of eight columns across the page. If the 
row has more than eight columns, the remaining 
columnswil I be listed directly below the preceding 
row. There will be a blank line between each row. 

Single Precision Floating Point 
The Matrix Package in its present form as designed 
for the DX-1 computer uses 8K Core Memory, the 
majority of which is used for data storage, and also 
uses three magnetic tapes (type 52 control), one of 
which is required; this being the System tape. 
Another tape is used only if magnetic tape input/ 
output statements are used. The third tape is used 
when the Eigenvector function is called on. The 
arithmetic used in this version of the Matrix Pack- 
age is single precision floating point. 
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DECAL-BBN 
(BBN Symbolic Version of DECAL) 

R. J. McQuillin 



Abstract 

The following talk reports progress on the new 
version of DECAL presently being completed 
at Bolt, Beranek and Newman. This version 
will have many new features. At this time 
a report will be given on the improvements 
to the existing system as well as the addition 
of ALGOL-like features to the algebraic 
compiler. 

Introduction 

For some time work has been going on for the purpose 
of making a good symbolic version of DECAL. The 
starting point was to produce a disassembly of the 
old DECAL F17C, which existed only as a binary 
tape. The disassembled listing was reorganized and 
written in DECAL symbolic form. After this first 
symbolic version of DECAL F17C was produced, 
work was begun on extensive rewriting of the system . 
DECAL F17C had been patched and modified so often 
there were many artifacts that were awkward and 
clumsy that were used so that things would compile 
properly. These artifacts have been removed in the 
rewrite. In fact, the rewrite has been so ex- 
tensive that the name of the system has been chang- 
ed to DECAL-BBN to reflect the differences between 
old and new systems. Particularly affected in the 
new version is the algebraic compiler. 

Inaddition to DECAL itself, the linking-loader fea- 
ture was also rewritten, partly to make it more ele- 
gant, and partly in order that it would be able to 
handle the increased capabilities of DECAL-BBN. 

The New Features of DECAL-BBN 
DECAL-BBN has been extensively debugged . (One 
of the drawbacks of older versions of DECAL were 
the errors in the system.) Inaddition, to correcting 
of eliminating errors the system has been made much 
more efficient, both in speed of compilation and in 
theeconomyof the compiler itself . The new version 
of the algebraic compiler is very efficient, in fact, 
temporary storage allocation is kept to a minimum 
at all times. 



The following completely new features have been 
added; 

1) Improved Typeout Format . In DECAL-BBN only 
error typeouts are done while a program is compil- 
ing . Al I other typing is done at the end of the com- 
pi lotion and only after all punching is completed. 
Inaddition, all typeouts may be suppressed through 
sense switch option. An action operator is written 
which will allow all the normal typing to be punched 
out at the end of compilation. Then the tape can 
be run off-line to get the listings. 

2) Conditional Statements . The conditional state- 
ments are handled exactly as described in the 
ALGOL manual. In ALGOL language: 



or 



if B then U else S 
if B then U 



where B is a Boolean expression; U is an uncondi- 
tional statement; and S is a statement. These items 
are the same as described in the ALGOL manual. 
As example, we may write conditional statements 
in the following ways: 

if A > b then goto c 
if (a > b) A (c % d) then d else goto e 
if a then goto belse if a > c then goto e 
ifa>b then c else d then goto e else goto f 

3) For Statements . The for statements are also as 
described in the ALGOL manual . They are of the 
formr 

for k <= F do S 

where k is a variable, F isa for list and S is a state- 
ment. These items are also described in the ALGOL 
manual. We may have for statements of the form: 

for i <= step 1 until n do S 
for i <= m,n step 1 until p do S 
for i <= step 1 while a < b do S 

4) Procedures . Procedures, as described by the 
ALGOL manual, are like subroutines in machine 
language. The differences are that they compile in 
a standardized way, and that they allow a variable 
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number of arguments. When a procedure designation 
is encountered in statement, a certain standard 
coding is produced. For example, suppose we have 
an expression like: 

a + J (l<,r) =>b 

Here J may be a procedure for finding the Bessel 
function arguments k and r. (Actually according to 
ALGOL, procedures that have a single value are 
called functions, so we may call J (k,r)a functional 
designation.) The coding that is produced here is: 

lac K 

[da J 

jac r 

add a 

dac b 

We may declarea procedure by using the expression : 

procedure J(k,x); B 

WhereBis thebodyof the procedure. We may also 
specify a definite result to be communicated back 
upon exit from the procedure. Thus, suppose we 
wish to find the Hankel function and return with the 
address of the first element of the two-element array 
which contains the results - the first element con- 
tains the Bessel function, and the second element 
the Neuman function. Then we would write: 

procedure H (k,r, H); result adr H; B 

5) Subscripted Variables. DECAL-BBN will have 
the capabilities of handling subscripted variables. 
It will actually produce an intermediate coding 
which will be handled by a subscript interpreter 
during run time. Thus we may write: 

A [i,j] +B [i,j] =>C [i,]"] 

A [ixj,k] +B [i/j,k] =>C[i+j,j+k,k+m] 

lac A [i,j] 

if A [i,j] > then goto b 

We may also have subscripts on subscripts. Thus: 

A [i[j]] =>b 
will be handled properly by DECAL-BBN. 

6) Hybrid Operators . DECAL-BBN has a new kind 
of operator called the hybrid operator. It is a 
combination of an instruction generator and an 
action operator. More precisely, it is an action 
operator with precedence. 



7) Address Arithmetic on System Symbols and Un- 
defined Symbols . Additions have been made to 
both the DECAL-BBN and to Linking Loader-BBN 
to make possible address arithmetic on system sym- 
bols and undefined symbols. Thus we may write: 

dss a 
jmp a + 1 
or lac a + 1 

a: . . 

The form for writing address arithmetic on Systems 
S or undefined symbols is not general but sufficient 
for most purposes. It must be of the form; the loca- 
tion followed by a (+) or (-), followed by an octal 
number. 

Other Features 

The basic structure or skeletal form of DECAL-BBN 
is such that it requires no further recompi lotion of 
the system. Supplementary, however, to this basic 
structure are separate tapes of action operators, in- 
struction generators and words. The programmer 
may select only those of the above that he needs 
and feed them into the basic system . Any modifica- 
tion of the basic DECAL-BBN is made through action 
operators, and not through recompi lotion. 

Recommendations for Increased Communications 
It is hoped that DECAL-BBN can be adopted as the 
standard compiler of the DECUS organization. The 
DECAL-BBN symbolic form makes possible the use 
of action operators . These action operators can then 
be communicated in their symbolic form to DECUS 
members. There is every indication that a standard 
programming language for PDP-1 users would insure 
a larger medium for communication. In addition it 
is hoped, that the algorithms as published in the 
Communications of the ACM will be easily and 
closely translatable into PDP-1 code, thus opening 
avast communication link to the whole computing 
community. 

Conclusions 

In this paper I have discussed only some of the new 
features contained in DECAL-BBN which will make 
it a more elegant system than its predecessor. The 
hybrid operator and the incorporation of ALGOL- 
I ike features described earlier make the new version 
a really useable tool for communication among PDP-1 
users and between the DECUS members and other 
computer users. 
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Section II 



PROBLEM ORIENTED TECHNIQUES 



MINIMAX DETECTION STATION PLACEMENT 
Richard D. Smallwood, Lt. 



Abstract 

One problem in the detection of enemy op- 
erations is the location of a given number 
of detection stations within a limited area . 
A practical requirement is that one assumes 
complete knowledge of the enemy of the 
effectiveness and location of the station 
net. This in turn necessitates a minimax 
solution of the problem, that is, the stations 
must be placed so that the minimum proba- 
bility of detecting an enemy event within 
the area is a maximum. 

The solution of the simpler one-dimensional 
problem, i.e., the placement of n stations 
on the unit line, has been programmed on 
the DX-1 computer. The program uses an 
iterative technique with typeouts and a dis- 
play available after each iteration. 

One problem thatarises in implementing a network 
for the detection of specific operations over an 
area of interest, is the optimum placement of a 
given number of detection stations. It is of par- 
ticular interest, to know where n stations should 
be placed in the area so that the probability of 
detecting an enemy operation is maximized. 

One assumption that is made in the analysis is that 
the enemy will know the effectiveness, as well as 
the position, of each of the stations. With this 
knowledge the enemy will certainly cause any 
operations to occur where our probability of de- 
tection is a minimum. Thus, the problem is to 
place the stations so that this minimum probability 
of detection is maximized. 

In solving this problem, we assume that we are 
given a function p(x) which is the probability of 
detection for one station if an event occurs a dis- 
tance x from the station. Furthermore, itis assum- 
ed thateach of the stations operates independently 
from the others so that the overall probability of 
detection, P, for an event is one minus the prob- 
ability that none of the stations detect the event: 



th 
where x; is the distance from the event to the i — 

station. 



This problem has not been solved for an arbitrary 
area; however, a set of necessary conditions for 
the optimum placement of n stations on the unit 
line has been derived (1). If we write the over- 
all probability of detection for an event occuring 
at X (0<x<l) as P(x), then these conditions require 
that the value of P at the end points, and the min- 
imum value of P between each pair of stations all 
be equal . 

The solution of this one dimensional problem for any 
number of stations and an arbitrary function p(x) 
has been programmed on the PDP-1. The optimum 
placementof the n stations is found by an iterative 
technique thatattempts to minimize a function that 
is a measure of the deviation from the optimum 
placement. If Oq is the value of P(x) at x=0, Op 
is the value of P(x) at x=l, and a? is the minimum 
value of P(x) between the iiJland (i+1) ^ stations, 
then the technique attempts to minimize: 
n . n 

to ' " i=0 I 

or the absolute deviation of each of the critical 
values of P from the average. 



In addition, the program displays a measure of P(x) 
on the color scope at the end of each station so 
that the convergence of the solution may be ob- 
served visually. 

Several interesting results have been obtained from 
this program. It is hoped that this work will lead 
eventually to the solution of the two-dimensional 
problem and in addition, to the solution of other 
more realistic extensions of the model. 



p=i -IT n -p(x.)"i 

[=1 U 'J 



(1) Small wood, R.D. "Detection Station Optim- 
ization - I" 

Project CAMBRIDGE Memorandum No. 5, De- 
tection Physics Laboratory, AFCRL, 9 July 1962 
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USE OF THE PDP-1 IN OPTICAL DESIGN 
M.V.Morello, E. J. Radkowski, M. P. Rimmer and R, R. Shannon 



Abstract 

The design of an optical system consists, in 
a basic manner, of solving n different non- 
linear equations in m unknowns. Often n 
and m may be of the order of twenty or more. 
The problem is further complicated by engi- 
neering and physical constraints as well as 
the fact that no definitive statement can be 
made as to when the best solution has been 
found . 

These problems will be discussed, and it will 
be shown how the PDP can serve as an ideal 
lens design computer. A demonstration of 
current programs will be given. 

Introduction 

The PDP-1 offers some unique and interesting pos- 
sibilities for applications to optical design work. 
Perhaps the best way to emphasize this is to outline 
what is the basic advantage. The PDP permits an 
optical designer to observe in "real time" the de- 
tails of the light distribution in an image. In es- 
sence, the machine communicates directly with the 
designer through the display. The designer can 
then react and make changes in the system via the 
typewriter, display or console. The aim here is 
not to use the machine as a gigantic sketch pad , 
but to usefully present a large amount of data in a 
usable manner. 

The lens design problem may be described as that 
of solving n non-linear equations in m variables. 
It is not uncommon for n and m to be each of the 
order of 20 or 30. Furthermore, there are non- 
linear boundary conditions on each variable and 
no well-defined way of knowing when a solution 
has been reached. Of course all of the parameters 
involved have physical significance. 

Now, how is the problem approached? A lens is 
set up as a starting point by deciding upon the 
focal length, aperture, field angle, spectral re- 
gion, intended use and desired resolution. From 
widely respected basic rules a starting configura- 



tion is picked. Traditionally, this starting point 
has been empirical, based upon the experience of 
the designer. With a computer, this is still largely 
true. However, the intelligent use of a computer 
permits one to investigate a large number of pos- 
sible solutions, and thus to develop a broad level 
of quasi-empirical experience within a short time. 
Thus the first major step in design is more or less 
mechanized. It has been repeatedly shown that 
there is no more sense in starting the design of a 
lens by randomly dropping glass blanks in a computer 
than there would be in designing a gas turbine by 
starting a program out on a pile of metal plates. 

The Design Process 

To proceed with the actual design process requires 
a short digression as to the model of an optical 
system which is used. 

The basic geometrical model of a lens depends upon 
tracing a geometrical pencil of light, that is a ray, 
through the lens using Snell's law. The product of 
index of refraction and angle with respect to the 
normal of a surface is conserved at the surface. 
That is, N sin I = N' sin I' . Between surfaces, the 
rules of analytic geometry are used to trace ray 
paths and to find the angle with the normal. To 
trace rays is a repetitive process and therefore 
ideally suited to a computer. Each ray, however, 
provides only a limited amount of data concerning 
the lens. Many rays originating from several ob- 
ject points are required to fully assess the state of 
correction of the lens. The measure of this state of 
correction or of the aberration residual of a lens 
is obtained from the size of the patch over which 
the rays spread in the image plane. An exact pic- 
ture of the geometrical characteristics of the lens 
may be obtained. 

To satisfactorily and completely analyze a lens may 
require tracing 100 rays in each of three colors at 
three field points, or about 900 rays , For a sample 
lens of six surfaces with one aspheric some inter- 
esting numbers are generated for the time required 
for doing this. See Table 1 below. 
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Time Required to Plot and Analyze a Sample lens of 
six surfaces with one aspheric surface. 

Calculation By By By 

of Human LGP PDF 

Ray 

Surface 

Spheric StolOmin « .^ ,-. _-. 

A , . , /o -11 2-13 sec 10-50 msec 

Aspheric 1/2 to 1 hr 

One Ray 1 hr-avg. 23 sec 1/10 sec 



900 Ray 



900 hours 
or 100 days 



5h 



rs 



90 sec 



Plot and 
Analysis 



2 days 2 days 



1 sec 



Table 1 

Obviously such an approach becomes really practi- 
cal only for a PDP type machine. 

The time required for hand work is so absurd that an 
entire approach using approximate techniques has 
developed over the years . This consists of expanding 
the sine of the angle of incidence to successively 
greaterorders of accuracy. Firstorder, or Gaussian 
optics, leads to formulae for magnification and 
image position. Third orderaberration theory gives 
the first aperture and field error terms which are 
separated into such aberrations as spherical, coma, 
astigmatism, distortion and curvature of field. These 
permita rapid but approximate picture of the state 
of correction over the field to be obtained. Fifth 
and seventh order theory extends the accuracy 
somewhat . 

Times again, are: 



Calculation 


By 


of 


Human 


One 




Surface 




3° 


2 min 


3 + 5 


15 min 



By 
LGP 



By 
PDP 



4-20 sec 1/1 0-1/2 sec 



Sample 
Problem 



12-90min 24sec2min .6-3 sec 



Output + 
Analyze 



5 min 
(Coeffs.) 



30 sec 
(Coeffs.) 



1 sec 
(Graphs) 



Obviously, an improvement. Using third order 
perhaps twenty to a hundred iterations may be re- 
quired for a solution depending upon the complexity 
of the problem. Using third plus fifth, ten to fifty 
iterations. Needless to say, the final stages must 
be carried out using exact ray trace data. A 
minimum ray fan for each final step would be as 
follows, for 51 rays. 



Human 


2 hours 


LGP 


3 min 


PDP 


5 sees 



Table 2 



Now, I believe you can see how the PDP can be a 
design partner. Economically, it is feasible to use 
the machine as such. 

Where do we stand now? We have working and are 
now using, third order, ray trace, and fifth order 
programs. We are working on refinements of these 
programs with respect to improving display commu- 
nication . At present we display the curves of great- 
est use to a designer. We will add new displays 
showing spot diagrams and the lens itself as time pro- 
ceeds. We also plan to add a certain amount of 
semi-automatic solving as an aid and adjunct to the 
display through the light pen. 

So far I have mentioned only geometrical optics. 
When the wave length of light is included, diffrac- 
tion occurs and must be taken into account. We 
have one general system analysis or study program 
which computes the spatial frequency response . This 
gives a picture of the lens response complete enough 
to be of use in accurately computing resolution and 
amount of information passed by the lens. In this 
regard the PDP serves as a research as well as an an- 
alytic and engineering tool. 

Our optics programs are extremely complex. The 
design package so far completed requires , with 
FLINT and lens data storage, about 6000 words. 
Obviously the disc display and low speed expanded 
memory are essential to complete integration of these 
programs. We require about 3000 to 3500 active 
core locations to work with. An exchange with the 
disc is obviously profitable. Our final package for 
design and analysis will probably use about 10,000 
to 12,000 instructions by the end of this year.* 
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*APPENDIX (added March 1963) 
The Optical Design Package has been integrated 
under a Master Executive routine which calls pre- 
stored programs from auxiliary disc storage. 

Ray Trace Intercept Curves 

Ray fans from on-axis, seven tenths and full field 
relative object heights are traced in the sagittal 
and tangential directions . The ray intercept curves 
in the image plane are plotted directly on the CRT 
and recursively displayed bythe Itek display system. 
Figure 1 illustrates these curves plotted from dif- 
ferent wavelengths. 



Spot Diagram 

By tracing a grid of rays arranged in a hexagonal 
close packed pattern and displaying the intercept 
points in the image plane on the CRT, it is possible 
to obtain an excellent approximation to the shape 
and structure of the image . 

The spot diagram shown in Figure 3 was calculated 
and displayed on the CRT for 511 rays in 150 sec- 
onds. A graph-plotter program reproduces the CRT 
display on an on-line graph-plotter so that the lens 
designer can take a hard copy image of the scope 
display with him. 




Figure 1 

Lens Drawing 

A scaled representation of the lens system is drawn 
on the scope from the lens parameters . Figure 2 
is an illustration of a lens drawing. 




Figure 3 

Lens Analysis Program 

Response characteristics for various spatial frequen- 
cies are also calculated and displayed on the CRT, 
Figure 4 illustrates an example from this program . 





Figure 2 



Figure 4 
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COMPUTER AIDED ANALYSIS OF 
MULTIVARIABLE SYSTEMS USING COLOR SCOPE 

CM. Walter 



In the investigation of many complex multivariable 
statistical and dynamical systems it is often suffi- 
cient to obtain a feel for the general behavior of 
the system. In order to achieve this "feel," it is 
necessary to construct and to evaluate a variety of 
mathematical models. This is usually a laborious 
task for very complicated systems and the usual se- 
quence of operations runs somewhat as follows: 1 . 
Aspecific mathematical model is constructed from 
physical insight into the system. 2. Computa- 
tional algorithms are prepared. 3. Computer pro- 
grams written, often not in close concert with the 
orginator of the problem. These programs are al- 
most always debugged in a messy fashion in a long 
series of bouts with an off-line processor. 4. Fin- 
ally, a run is made and a large amount of tabulated 
data is placed in the hands of the problem origina- 
tor. 5. Graphs must then be prepared in order to 
see what is going on. This whole operation is then 
carried out repeatedly, with the outcome at any 
given stage usual ly either unavailable, or only par- 
tially transcribed from relatively useless tables in- 
to intelligible graphical form, before a decision 
on the next sequence of off-line computer runs can 
be made. 

Oneof the principal motivations behind the Exper- 
imental Dynamic Processor, DX-1, at AFCRL was 
to provide a research vehicle for studying the util- 
ity of closer man-machine communication in pro- 
vidinga better feel for the behavior of various sur- 
veillance and other sensor information processing 
systems . 

Since most of the sensor attribute extraction tech- 
niques, and other signal filtering machines, involve 
an extensive matrix manipulation capability, con- 
siderable effort has been put into the development 
of a matrix handling package for the PDP-1 type 
machine. The preliminary version of this package 
has been described in a previous article by Carmine 
Caso of the Wolf Research and Development Cor- 
poration. A primary objective of this utility sys- 
tem is to facilitate on-line matrix manipulation . 
Also, in order to make effective use of the color 
scopeasa graphical outputmedium, andasa mech- 
aism for manual intervention for the purpose of 
rapid parameter and function a Iteration it has been 



necessary to underwriting the development of an 
elaborate system of display utility programs. This 
work will be reported onata later date. Sufficient 
routines existat the present time, however, to give 
the following cursory illustration of the potential 
of this sort of approach. 

One of the most important processes underlying a 
wide variety of problems inmany areas of dynamics , 
statistics and of signal analysis, is the eigenfunc- 
tion, orstationary mode description process. Con- 
sequently we have begun to evolve a series of con- 
trol procedures to simplify the study of this complex 
process. 

The determination of all of the eigenvectors and 
eigenvalues associated with a large matrix can be 
prohibitively time-consuming, and is usually un- 
necessary, particularly when the given matrix is 
obtained from a sampling process, oris only an ap- 
proximation to some complex interaction process . 

Akey problem, therefore, is to know when to ter- 
minate the iterative procedure which is attempting 
to determine the set of e i gen vec tors ,i-jik^, and 
eigenvalues, f^^, of the matrix j^. i.e., the 
solutions of the implicit equation A u =\<^. An- 
other related problem is to obtain a feel for the 
degree of stability of the eigenvectors under small 
perturbations about their estimated positions . 
These are questions which are almost impossible to 
answer analytically, except in trivial situations, 
or in terms of very crude bounds. 

Through the use of the color scope and light pencil 
on the DX-1 itis possible, (see figure 1) to exhibit 
a particular estimate for some eigenvector, u, as 
asetof points, (u,,..., u ), in one color (blue) , 
with the abscissa corresponding to the coordinate 
numberandthe ordinate indicating the coordinate 
valueof then-dimensional vector. Any variant of 
this vector, say v, can then be entered, via the 
light pencil, (see figure 2) in a different color, 
(green) and the resulting transformed vector W ( = 
^v ) is exhibited, by the computer after suitable 
normalization, in still another color, (red) to see 
how near it is to u. (See figure 3.) 
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Another capability of importance in studying the 
overall convergence problem, is to exhibit the suc- 
cessive iterations tending toward a given eigen- 
vector in different intensities of one color, with 
the most intense hue corresponding to the most re- 
cent iteration for that vector. Tendencies of the 
system to oscillate or to exhibit other anomolies 
then stand out clearly in terms of the visible past 
history showing both the rate and nature of con- 
vergence. 

These techniques provide a very effective and el- 
egantmeansfor studying the stability and conver- 
gence properties of selected eigenmodes of the sys- 
tem under investigation, both as a function of pur- 
turbations in the eigenvector component values and 



as a function of the particular analytical repre- 
sentation of the system. E.g., whether it is char- 
acterized in termsofa differential system of equa- 
tions or in some equivalent integral equation form- 
ulation. Often the algorithmic description need- 
ed for purposes of computation will introduce spur- 
ious instabilities which are extermely difficult to 
evaluate analytically, and which have no "phys- 
ical" counterpart in the actual system under in- 
vestigation. 

In resolving problems of the above sort, the cap- 
ability for having the originator of the problem in- 
teractdirectly with the problem as it is running on 
the processor leads to very greatsavings in the over- 
all time needed to get the requisite understanding 
of the behavior of the model under investigation . 
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Figure 1 . First Eigenmode of Vibrating String u 
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Figure 2. Variation on First Eigenmode v 
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Figure 3. Response to Variation w 
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A WORLD OCEANOGRAPHIC DATA DISPLAY SYSTEM 
Edward Fredkin 



Abstract 

Thepurposeof the world oceanographic data 
display system is to enable a researcher to 
conduct an analysis of oceanographic data 
using a series of visual displays generated by 
a digital computer. The eventual goal of the 
program will be the design of a computer sys- 
tem capable of storing the entire body of 
world oceanographic data and making it 
available for visual display and analysis . 

The researcher will be able to select specif- 
ic data for display, in the form of contour 
lines against a map of a selected oceanic 
area. He will be able to vary the parameters 
of the data selected, and observe the re- 
sulting variations in the contour lines. It 
isanticipated that the world oceanographic 
datadisplaysystem will open up the present- 
ly available body of oceanographic data to 
a rapid and meaningful analysis by oceano- 
graphic researchers. 

Introduction 

Oceanographic data has been collected over the 
course of many years. This data may, typically, 
take the form of readings (at a specific location) 
of temperature, degree of salinity, percentage of 
oxygen content, and density at varying depths. It 
is generally collected in the form of water samples 
taken during the course of oceanographic expedi- 
tions. Thus, at the present time, a vast amount of 
oceanographic data has been collected; the task of 
analyzing this data manually presents formidable 
difficulties. 

Description of System 

The World Oceanographic Data Display System will 
consist of a PDP-1 computer with a magnetic tape 
unit, a cathode ray tube visual display unit, a light 
pen, an input-output typewriter, and control 
switches. Oceanographic data will be stored on 
magnetic tape and will be processed and displayed 
by appropriate programs. 

Method of Operation 

In operation, a world map will appear on the CRT 



visual display unitof the computer. The researcher 
will then designate a specific geographical area 
(e.g., the South Atlantic) for enlargement on the 
visual display scope by pointing a light pen at the 
desired geographical area. He may then select a 
sub-area within the South Atlantic area for en- 
largementand display in the same manner. He may 
continue this process until the desired degree of en- 
largement has been obtained. 

At this point the researcher, by typing an appro- 
priate symbol on the input-output typewriter, will 
instruct the computer to transfer oceanographic 
data for the selected region from magnetic tape 
storage into the computer memory unit. It isantic- 
ipated that data to be used in the World Oceano- 
graphic Data Display System will include the lat- 
itude, longitude and identification number for each 
oceanographic station,^ and for each recorded 
depth at the station, the following information: 
(See figure A) (1) temperature, (2) salinity, (3) 
oxygen percentage and (4) density, or specific vol- 
ume anomaly. Afterdate read-in has been accom- 
plished, two additional features will appear on the 
visual display scope. First, super-imposed on the 
area map selected for visual display will appear a 
number of i I luminated dots . Each dot wi 1 1 represent 
the location of a specific oceanographic data sta- 
tion. All oceanographic data stations in the se- 
lected area will be represented by these light dots . 
Second, five thermometer-type data indicator 
scaleswill appear in the lower righthand corner of 
the visual display scope. These will represent (1) 
depth, (2) temperature, (3) salinity, (4) oxygen 
percentage and (5) density. They may be used by 
the researcher to select modes of data display in 
following manner. 



The researcher may indicate a specific depth on the 
depth indicatorscale with his light pen.^ He may 
also indicate a specific value for one other para- 
meter on the appropriate indicator scale in the 

someway. Forexample, hemay designate a depth 
of five hundred meters and a temperature of five 
degrees centigrade. 
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This will cause all stations reporting temperatures 
of five degrees or higher at a depth of five hun- 
dred meters to appear as bright dots on the visual 
display scope. Stations reporting temperatures 
lower than five degrees at a depth of five hundred 
meters will appear as dim dots on the visual dis- 
play scope. In this way a "temperature gradient" 
will be outlined on the visual display scope in the 
formof a brightly lit (or, conversely, a dimly lit) 
area. 

Combinations of Data for Analysis 

The World Oceanographic Data Display System will 

make possible the analysis of data in the following 

combinations: 

(1) depth vs. temperature 

(2) depth vs. salinity 

(3) depth vs. oxygen percentage 

(4) density vs. depth 

(5) density vs. temperature 

(6) density vs. salinity 

(7) density vs. oxygen percentage 

in this way the researcher will have available a 
rapid and flexible method of determining the re- 
lationships which exist (a) withina given setof two 
parameters and/or (b) between several individual 
parameters. 



Other Capabilities of the System 
The researcher, in the conduct of his analysis, may 
note an anomalous station displayed on the scope . 
By pointing his light pen at this station, he will 
cause to be displayed on the scope the name of 
the cruise and other pertinent information. He can , 
if so desired, cause this information to be typed out 
by the computer for purposes of maintaining a per- 
manent record. In this connection, the computer 
system will be able to accept and record comments 
(together with the name of the user) regarding the 
validity of recorded data; such information will be 
retained by the computer and made available to sub- 
sequent users upon request. 

Summary 

Access to the vast body of oceanographic data has 
been at best slow, difficult, and in many cases im- 
practical under manual methods of data analysis . 
The World Oceanographic Data Display System 
would immediately open up the large body of data 
now available in computer-readable form to rapid 
and meaningful analysis by oceanographic research- 
ers. Inthissense it would serve as a technological 
stimulus which might lead, inturn, to rapid and ex- 
tensive advances in the state of the art of world 
oceanography. 



Each location where oceanographic data has been 
collected (e.g., by use of an oceanographic cur- 
rent meter) is referred to as an oceanographic 
"station." 



Density may be similarly plotted against other 
parameters. 
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THE VORTEX OCEAN MODEL 
Edward Fredkin 



Abstract 

The Vortex program is a computer program 
written for the PDP-1 computer. This pro- 
gram simulates a Vortex Ocean Model and 
displays the results of the simulation on the 
computer scope. In addition, the computer 
collects certain statistics on the model, and 
allows a researcher to control the configu- 
ration of the simulation by appropriate en- 
tries made on the input-output typewriter. 
At any time during the computation, the 
value of any of the variables in the compu- 
tation maybe examined or changed by using 
the typewriter. In addition, certain of the 
variables maybe given a random assignment 
of values by pressing a single key on the 
typewriter. 

In general this program allows a researcher 
to work with the Vortex Ocean Model so as 
to gain familiarity and understanding of the 
behavior of the model . 

In the Vortex Ocean Model, a set of vortices 
interact in a circular or in an unbounded 
ocean. The number of vortices may be var- 
ied from one to thirty-one. In addition, 
there is a special test point which is used to 
collect statistics on the effects of the vor- 
tices. Each vortex rotates with a strength, 
where the i*"" vortex rotates with strength 
S] . When the direction of the rotation is 
counterclockwise, it is positive; clockwise 
rotation is negative . The rotation of each 
vortex affects the position of all other vor- 
tices. This effect is in direct proportion to 
the strength, and in inverse proportion to 
the distance . 

This program performs all computations in 
fixed point, which is essential in order to 
gain the desired speed of computation; how- 
ever, most input and output is handled by a 
floating point system. The program, not 
counting tables, isapproximately 3600 (dec- 
imal) registers long. It operates with suf- 
ficient speed to show several vortices in 
operation, flicker-free. 



An unusual feature is that the program auto- 
matically tests to see whether the computer 
is standard, has the optional high-speed 
multiply and divide, or has the Itek type of 
divide. In each case it modifies itself ap- 
propriately in order to take complete advan- 
tage of the capabilities of the computer . 

The Vortex Control System 

The Vortex program is controlled from the type- 
writer. At any time, during the operation of the 
program, various parameters may be examined or 
changed. In addition, the computation or various 
parts of it may be halted, continued, or restarted 
atwill. In general the Vortex program is controlled 
by typing certain letters on the typewriter. These 
letters are called "control characters." When a 
control character is typed, the appropriate action 
is taken, and the program continues. Certain con- 
trol characters, in particular those that are directly 
related to the value of some parameter, usually be- 
have in the following fashion: when theyare typed, 
the value of the corresponding parameter is printed. 
In order to change the value of a given parameter, 
the character slash [/]* is used. Slash always 
changes the value of the parameter last referred to. 
A parameter may be changed as often as desired 
without retyping its control character, just by re- 
using the slash [/] . 

Some variables are put into the program and printed 
out by the program in floating decimal, i.e., as a 
decimal number with an exponent. For example , 
the value of pi would be printed [+3.1416f0] mean- 
ing 3.1416x10^, The number of feet in a mile 
would be typed out as follows [+5.280C>f3] which 
is interpreted as 5.2800xl03 or 5280. The number 
of seconds in a memory cycle, 5 microseconds, 
would be printed out as 5.0000-6. When numbers 
are being typed in, no such rigid rules need to be 
followed. The actual number typed may have a 
decimal point or the decimal point may be omitted 
as you like. If the decimal point is omitted the 
number is assumed to be an integer. This number 



*Square brackets will be used to indicate the exact 
string of characters that are typed out or typed in . 
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is then multiplied by -10 raised to the power of the 
number immediately following the first number. The 
input of a floating decimal number is terminated by 
the first non-numeric, non-sign or decimal point 
encountered. Thus, pi may be put into the com- 
puter in any of the following formats. [3.14159], 
[31416-4a], [+3.14159+0], [ + .00031 41 6+4z ] . 

A decimal integer is typed in as a string of digits 
preceded by a sign, where the plus sign is option- 
al, and terminated by any non digit. 

Following is a table of the control characters and 
their functions. 

[t] The value of At, the time increment, is 
printed. The value of At may be changed by use 
of the slash. The value of At is typed in floating 
point format, -2< At<2. 

[k] The value of the parameter k is printed. The 
value of k may be changed by use of the slash. 
The value of k is typed in floating point format, 
-256<k<256. 

[c] The value of the parameter c is printed. The 
value of c may be changed by use of the slash. 
The value of c is typed in floating point format, 
-256<c<256. 

[n] The value of the parameter n is printed, n is 
the number of vortices in the system, not counting 
the test point. The value of n may be changed by 
typing the slash. The value of n is typed as an 
integer, 1 <=n <=31 , 

[i] The value of the parameter i is printed, i is 
the current value of the index for subscripted quan- 
tities. Some of the parameters, namely x, y, and 
s, have a value for each of the n points and also 
for the test point. In order to examine these values 
for a given point, the parameter i is set to a small 
integer, i < n. Once the value of i is set, it re- 
mains at tFTat value until it is changed. In order 
to examine or change the parameters of the test 
point, i is set to the value zero. The value of the 
index, i, may be changed by use of the slash. The 
value of i is typed in as an integer, < i < 31 . 

[x] The value of x; is printed. The value of xj 
may be changed by use of the slash. The value of 
i must have been set previously. The value of Xf 
is typed in floating point format, -1 <xj<l . 

[y] The value of yj is printed. In all respects the 
same as for x . 



[s] The value of sj is printed. In all respects the 
same as for x . 

[p] The value of p is printed, p is a parameter 
that controls whether the vortices are affected by 
the boundary, p is a decimal integer that must be 
set to one of three different values, 0, -0, 1 . If 
the value of p is 1 , then the vortices will be affected 
by the boundary. This is done by computing image 
vortices and computing their effects on the normal 
vortices. If the value of p is 0, the computation 
will proceed as before, however, the vortices will 
be uneffected by the image vortices. If the value 
of p is -0, most of the computation for computing 
image vortices will beskipped. The only difference 
between the value and -0 is one of timing; the 
total difference in computation time between the 
value and 1 is negligible, while with value set 
to -0 the speed of the program is measurably in- 
creased . 

[r] The control character r is a toggle switch. 
Every time [r] is typed, the program changes from 
one of two states to the other. The function of r 
is to freeze the computation, and to display addi- 
tional data on the scope. If [r] is typed again the 
computation will continue, if r is then pressed again 
it will freeze, etc . When the computation is frozen 
by means of r, the values of the variables remain 
constant, e.g., there is no change in any of the 
x's, y's or strengths (s's), and the statistics remain 
constant. Various parameters may be examined and 
changed while the computation is frozen. In case 
of certain types of errors, after an error print indi- 
cating the type of error and where in the program 
the error occurred, the computation will be auto- 
matically frozen. 

[a] The value of a, the radius of the circle that 
is used as the boundary in the image computation, 
is printed . The value of a is typed in floating point 
format, -4<a<4. 

[o] In order to display the circular boundary, the 
letter o may be typed, o is a toggle switch as is 
r, the boundary appearing and disappearing with 
each subsequent type of the letter o. Displaying 
the boundary will noticeably slow down the com- 
putation and display. 

[b] The control character b stands for beginning. 
Beginning sets a new set of random numbers in X|, 
yjands|. For all values of i other than i=5o . Thus, 
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all points are assigned random positions and strengths 
except for the test point. The random numbers 
used range uniformly -l/4< random variable <+l/4. 
Thus the points are more or less grouped in the cen- 
ter with fairly small strengths. Beginning also re- 
sets to zero the statistics and cycle count. 

[v] The control character v restarts, the same as 
does the control character b, however, v will 
always restart with the same table of random num- 
bers asdid the previous b. Thus, once an interest- 
ing display results from typing the letter b, it may 
be repeated as often as desired by typing [v] . 
When restarting, the statistics and cycle are reset 
also. 

[h] Typing [h] will cause the vortex program to 
type all the statistics. The statistics typed out will 
be (1) the total time, (2) the average value of dx 
for the test point, (3) the average value of dy for 
the tes t poin t, (4) the variance of dx fo r the te st 
point (d x-Sx)^ , ( 5) the v ariance of dy (dy-Jy)2, 
and (6) (dx-dx) x (dy-Jy) . 

[d] The display routine. In order to allow the 
insertion of a title, which will be displayed on the 
scope whenever the computation is frozen, type 
[d] followed by a title. When typing the title, the 
choice of characters is unlimited, except that tabs 
and carriage returns should not be used, and the 
title should be no more than 50 spaces long. Al- 
though the message must not exceed 50 spaces in 
length it may actually contain more characters be- 
cause of the upper and lower case characters, and 
non-space characters. When you have finished 
typing in the title, then move sense switch one up 
and down to indicate so to the program. 

[m] Restart statistics from zero. If it is desired 
to start the statistics at zero this may be accom- 
plished by typing the letter m. This will set the 
number of cycles, the time, and all statistics to 
initial values. 

[z] The control character z is used to set the f 
function table. This allows a fairly automatic set- 
tingof all the values of the ffunction table. After 
typing [z] the program will type out the word 
[base], at this point a floating decimal number 
should be typed in. Next the program will type 
out the word [top] which should be followed by 
typing in another floating decimal number then the 
program will type out [+ or -/] which should again 



be followed by a floating decimal number. All 
these numbers affect the value of the entries in the 
f table. Let us assume that three numbers typed in 
are represented ^y 0( , n , and^ respectively , 
then the allowable range of these numbers would 
be determined as follows, -256<p<- V, p +2f<256. 
The f table consists of 32 different values the entire 
table is filled after the typing of the three numbers. 
y, which is typed after the type out [+ or -/] , is 
the range of a uniformly distributed random variable 
that is added to each value put into the table . This 
value may be set to zero . For the 32 entries in the 
f table, (fo through f3]) f and f3] are set to the 
value typed after [base] , <^ . Then the values of 
the entries in the f table are increased linerly until 
at f"!^, they are equal to >Oat which point they are 
decreased linearly until at f3] they are equal to 
«?<'again. After this is done, the random variables 
are added to this trangular like array. 



100- 



ForOC =-25, >^ =75, JJ =15 
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^^50- 



0- 
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[f] The control character f allows an entire table 
to be typed in, all 32 values, or just 1 value. Once 
the letter f is typed, the program will type out 
[f-table, a or 1?] . In order to change all of the 
f table, type [a] . To change any given member 
[ 1 ] , the digit one . 



When Changing One Value of f 



m 



When typing in just one value, the program will 
print [m= ], this indicates that a value for m should 
be typed in, m is an integer, 0<m<31 . The value 
of f^ will be printed. The value of ff^ may be 
changed by use of the slash, f^^ is typed in floating 
point format, -256<f^<256. 

When Changing All of The f-table 

The value of the subscript m (0<m<31) will be 

printed, then type in a value for f^. The value 

of the subscript m will be increased by one and 

printed, etc. f^ is typed in floating point format, 

-256<fm<256. 
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The Error System 

The Vortex program, has a general and fairly elab- 
orate error detection system. The types of errors 
detected are those caused by overflow. In order 
to speed the computation, ail internal calculations 
are done in fixed point. This means that for each 
variable, the smallest change in value is equal to 
approximately 1/250,000 times the range of that 
variable. Should the result of any computation be 
a number outside the range of the variable that is 
being computed, then an overflow condition exists 
and an error print will occur. The error print is of 
the form the letters [err] in red followed by a two 
letter code, also in red, followed bytheoctal loca- 
tion of the offending instruction . At this point the 
computation freezes and various registers may be 
examined or changed or the computation restarted 
by means of the typewriter control features. 



Facts About The Vortex Program 
The Vortex program is coded in the DECAL lan- 
guage. The format used is almost entirely the in- 
struction word statement, as this program needs to 
operate in real time and needs to be very fast. 
Features of DECAL were used to make this program 
compatible between machinesthat use multiply and 
divide as built-in instructions and those that use 
subroutines. The Vortex program itself consists of 
approximately 1,400 (1,400 decimal) instructions. 
Room for up to 32 vortices is contained in a table 
352 registers long. Various subroutines and their 
tables used by the vortex system add an additional 
2,200 registers to the program, for a total of about 
4,000 registers (the memory contains 4,096 regis- 
ters). The major subroutines used are the floating 
point system which is used for input and output and 
certain computations, the in-out subroutines, and 
the display subroutines. 
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SPACEWAR.' 
REAL-TIME CAPABILITY OF THE PDP-1 

J. M, Graetz 



Abstract 

file game starts with each player in control 
of a spacesh Ip (shown on P DP scope) eq uipped 
with propulsion rockets, rotation gyros, and 
space torpedos . The use of switches to con- 
trol apparent motion o f displayed objects 
amply demonstrates the real-time capabil- 
ities of the PDP-1 . 

Introduction 

The demonstration program known as SPACEWARi 
was first conceived in December, 1961 at an in- 
formal gathering of the Hingham Institute where 
Wayne Wiitanen, Stephen Russell, and the author 
were discussing some of the possibilities of the use 
of the large -screen CRT which was to be attached 
to the new PDP-1 computer at M.I.T. One idea 
that caught our fancy was the thought of a moving 
display under the control of the user. We thought 
that a simulation of ships in space would provide 
an excellent demonstration and the discussion de- 
veloped into the Hingham Institute Study Group on 
Space Warfare, under whose auspices almost all 
of the work described here was done. The main 
control and computation programs were written and 
debugged in the first months of 1962 by Stephen R. 
Russell of Harvard. 

The program is set up in the form of a game for two 
persons and a PDP-1 . Each person has control over 
one of two displayed spaceship outlines. The object 
of the game is to destroy the opponent's ship by 
blasting him out of space with torpedos. Control 
is maintained over the ship's orientation by simu- 
lating rotational gyroscopes. All translation is 
achieved with the ship's main drive rocket; the ship 
will accelerate in the direction its nose is pointing 
as long as the rocket engines are turned on . Both 
ships are armed with ballistic missiles (torpedos) 
which are released from the nose of the ship with a 
velocity equal to the ship's velocity plus that im- 
parted to the missile by the launcher. From then 
on, the torpedos are in true bollistic flight. Each 
ship has one other means of getting from one place 
to another, namely "hyperspace," which allows 
him to get out of the way quickly. 



The display includes a background of stars and a 
bright, flickering star or "heavy star" in the center 
of the scope which maintains a rather fierce grav- 
itational field. 

The Game 

At the be ginning of the game two spaceships, 
equipped with 31 torpedos, are displayed in diag- 
onally opposite quadrants of the scope face. The 
players operate switches for the purpose of maneu- 
vering into position for joining the fray. (It is un- 
wise to remain in a single position for a very long 
time, and also fruitless, for the torpedos have only 
a limited range.) The torpedos have two types of 
fuze: one is a proximity fuze which causes the 
torpedo to explode when it comes within a certain 
critical distance of a n y other collidable object 
which will also be caused to explode. The other 
is a time fuze which causes the torpedo itself to 
explode if it has not encountered another object 
after a given length of time. 

The "heavy star" in the center is constantly exert- 
ing a strong gravitational influence on the two 
spaceships (torpedos are not affected by gravity). 
This star also hasa very short capture radius; a ship 
with reasonably large intrinsic velocity can come 
in quite close to the star without fear of being cap- 
tured. This maneuver is frequently used to change 
direction rapidly. 

If a ship is captured by this star, it loses all velocity 
and is thrust into the "anti-point," that point on 
the surface of a topological ly toroidal scope which 
is represented by the four corners of the face . 

All collidable objects explode on coming into crit- 
ical range. The current rules require that a game 
is won only if the remaining ship (after the opponent 
has exploded) can successfully avoid being blown 
up by any torpedos which may be left over. A tie 
is declared: when both ships collide (and explode); 
when an apparent victor is destroyed by a loose 
torpedo; or when both ships run out of torpedos. 
(Each ship has 31 torpedos at the start of each game). 
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The Spaceships 

The two ships have different outlines making them 
more easily distinguishable on the scope face. Ro- 
tation is readily apparentand rocket blast is equal- 
ly detectable. When the ship is blasting, a fiery 
tail is seen at the base of the ship, where the main 
rocket exhaust is placed. The spaceship outlines 
are generated and displayed by a program written 
by Daniel Edwards of M.I.T. This program pro- 
vides a very fast and reasonably flicker-free dis- 
play. Torpedos appear as single moving dots. They 
resemble stars rather closely. 

The Heavy Star 

A bright, flickering point in the center of the scope 
represents the massive star referred to as the "heavy 
star." This star has a strong effect (which approx- 
imates gravitation) on the two spaceships. The 
programforthis was also written by Daniel Edwards. 
In the final version of SPACEWARD he is going to 
provide an improved integration to eliminate some 
of the more unexpected, albeit interesting, pro- 
perties of the "heavy star." 

The Stars of the Heavens 

To add verisimilitude to the display, a background 
of stars is provided. At first, this was merely a 
random display of dots. However, Peter Samson of 
M.I.T. has written a program which displays a star 
map of the sky as seen from the Earth's equator. 
The size of the scope limits the extent of the map 
to a 45° segment of the heavens . Stars down to 
|ust above fifth magnitude are displayed. The dis- 
play moves imperceptibly across the face of the 
scope from left to right, and, given time, the com- 



plete band of stars of this section of the map will 
be displayed. 

Hyperspace 

This is an emergency device. It frequently happens 
that a ship cannot accelerate fast enough to get 
out of the way of an approaching torpedo. The 
player may send the ship into hyperspace then. 
The ship then will disappear and very shortly will 
reappear somewhere else on the scope. Since this 
isawayof getting from one place to another with- 
out traveling the distance between, the method 
used must be hyperspace.' Each player has exactly 
three hyperspace jumps. 

On most PDP-ls, the shipsare controlled byswitch- 
es in the Test Word. For the M.I.T. machine, 
however, two control consoles were devised by 
Robert A. Saunders and Alan Kotok, both of M.I .T. 
Each console has a double-throw switch to control 
rotation, a firing button, and a blast lever. Hyper- 
space is entered by pushing the blast lever forward 
and releasing. 
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Figure 1 A Common Openrng Maneuver 
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ON-LINE PROCESSOR-ORIENTED 
INVESTIGATION OF A CLASS OF DYNAMIC ATTRIBUTE 
EXTRACTION AND CLASSIFICATION PROCESSES 

C. M. Walter 



Abstract 

A method for the comparative evaluation of 
a wide class of self-adaptive attribute ex- 
traction and classification procedures is de- 
scribed. This method involves the on-line 
use of a medium size digital computer cou- 
pled to a colored CRT display. Multichannel 
sensor information, or numerical test data, 
to be abstracted and classified, can be en- 
tered into the system from paper tape, or 
through an A-D converter, or manually, by 
use of light-pencil, CRT and keyboard . Both 
raw sensor data, its representation in the 
form of abstracted attributes, and its recon- 
struction from incomplete sets of attributes 
can be viewed simultaneously on the CRT 
output. On-line keyboard and light-pencil 
control provide an excellent mechanism for 
investigating the structure of the various 
complex transformation processes which are 
involved in this approach to the consolida- 
tion and interpretation of sensor information , 

1 , Introduction 

The development of increasingly more elaborate 
sensors and measuring devices for obtaining em- 
pirical information about the environment, has led 
to a continuing crisis in the information processing 
domain. Improvements in radar, radio, and seismic 
detection devices, together with the advent of a 
variety of energy detecting satellites, is creating 
growing mountains of unprocessed data. The poten- 
tial of this data, for purpose of military surveil- 
lance, andalso as a source of scientific knowledge, 
often diminishes rapidly with its age in a raw, un- 
processed state . 

Unfortunately, the cost of directly operating on 
this sensor data with the present generation of dig- 
ital "data processors" (actually logical symbol ma- 
nipulating devices) is proving to be too costly. 
Much of the current effort in pattern recognition 
and on the application of artificial intelligence 
to this domain, seems to be addressed primarily to 



the symbol manipulating aspects of the problem. 
The more fundamental matter of extracting appro- 
priate sets of intrinsic attributes, together with both 
the syntactic and semantic rules governing their 
behavior, has only been treated by a few groups. 

In large measure, the difficulty arises because the 
canonical attributes, which behave according to 
reasonably simple logical or mathematical rules, 
have to be obtained from the raw sensor data by a 
process of statistical and dynamical abstraction. 
These attributes are usually not the measured out- 
puts of the various sensors, and are generally re- 
lated to these raw measurements in a complex multi- 
variate statistical -and dynamical -manner, which 
depends upon both the process under observation 
and also the measurement process itself. 

Thus, the primary problem is not so much one of 
symbol manipulation according to specified rules, 
asthatof determining what the rules should be, and 
of establishing meaningful interpretations for the 
symbols. Under this viewpoint, the problem of 
effective dynamic processor design is inseparably 
tied to the general measurement problem. 

It is, therefore, only reasonable that we should 
investigate in detail various important classes of 
dynamic attribute extraction procedures, together 
with possible mechanisms for efficiently realizing 
these procedures. A step in this direction is the 
on-line simulation ofvarious classes of these sensors 
attribute extraction procedures, using an orthodox 
digital data processor, to which suitable graphic 
input-output devices have been added . ^ The slow- 
ness and inefficiency of this type of simulation, 
on sequential processors, clearly calls for the de- 
velopment of a parallel processing capability which 
at least covers the manipulation of the linear asso- 
ciative matric algebras needed to characterize the 
basic measurement and attribute extraction process. 



Walter, CM., "The Experimented Dynamic Pro- 
cessor DX-1," Part9, 1962 IRE International Con- 
vention Record, March, 1962. 
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Since appropriate physical realizations must be pro- 
vided for the matrix elements, in terms of the non- 
canonical coordinatesassociated with the raw sensor 
measurement processes, this is not an easy task. 
However, the use of electro-optical storage mech- 
anisms and parallel processing techniques should 
materially aid in these realizations. 

2. The General Problem 

The emphasis in this report will be on the develop- 
ment of on -line data processing techniques for eval- 
uating a class of dynamic attribute extraction and 
classification procedures. The particular class of 
procedures to be implemented is based on a synthe- 
sis of methods from multivariate analysis, statistical 
mechanics and the quantum theory of measurement 
processes, as applied to the non-atomic domain, 
and is discussed in detail elsewhere.^ 

The categories of data to which these techniques 
are most relevant are those in which the important 
attributes are not clearly discernible from direct 
examination of the raw measurement data. This is 
particularly true of target signature identification 
problems in the surveillance area, whether the 
basic mechanism be radar, I.R., radio forward- 
scatter or back-scatter, or sonar. It is also true of 
bioelectric signals such as EEG and ECG data . In 
all of these examples the significant, structural 
attributes are highly interrelated, in terms of the 
raw sensor data, in both a statistical and a dynam- 
ical manner. Any process which attempts to un- 
scramble this data must seek the natural invariants 
of the system and determine a suitable basis for the 
exhibition of these invariant attributes. 

3. Approach 

The attribute extraction processes under investiga- 
tion may be resolved into six interrelated phases: 
1) raw sensor data description; 2) intrinsic attribute 
derivation; 3) interpreted data description in terms 
of intrinsic attributes; 4) truncation of interpreted 
data; 5) resynthesized sensor data from truncated 
interpreted data; 6) comparison of raw and resynthe- 
sized data . 

3.1 The first phase is concerned with the consol- 
idation of the raw sensor data, x, into a family of 
descriptors, <5 , from which an interaction func- 



2 
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tion, F is formed, along the lines delineated in 
Appendix A, Section 1.1 (A-1.1). The tabular 
description of raw sensor input data is outlined in 
A-4.3. A similar format of colored points is used 
to exhibit the x data on the color CRT attached to 
the DX-1 System. Means are provided for input- 
ing the data, either through the scope under light 
pencil control, or from mag tape, with light pencil 
editing. In the scope display the t-coordinate is 
horizontal, rather than vertical, as in the printout. 

3.2 The second phase involves the construction of 
a transformation, u, from the sensor data coordinate 
basis^to a new basis of intrinsic attributes, in terms 
of which the interaction function possesses the sim- 
plest structure in the sense of least interaction be- 
tween isolated attributes. The specific mechanism 
chosen to achieve this goal is the eigenfunction 
procedure specified in A-1 .2 . The tabular descrip- 
tion of the eigenvector attribute filters is discussed 
in A-4.2. 

3.3 Then, using the eigenbasis determining pro- 
cedure, it is possible to provide an interpreted data 
presentation, ^ , in which the intrinsic attributes 
characterizing the process under observation are 
ordered in such a manner that the least significant 
attributes can be most readily neglected. This is 
particularly important for purposes of information 
transmission and storage . Procedures for construct- 
ing this interpreted information are discussed in 
A-1 .3, and the tabular mode of description is pre- 
sented in A-4.4. The associated graphic CRT dis- 
play is arranged with t-coordinate horizontal and 
aligned directly under the associated x dataon the 
CRT for viewing convenience. 

3.4 At this point the interpreted data is arranged 
in a format (cf. A-4.4) which permits three kinds 
of controlled information degradation. We can 
eliminate interpreted data in all channels whose 
associated eigenvalues are less than a given value, 
as outlined in A-1 .4. Another information reduc- 
tion process which can be investigated at this point, 
but which has not been explicitly implemented in 
the present program, is to quantize the range of 
values of the (p function in a progressively coarser 
manner. The third mechanism for controlled infor- 
mation reduction, is to select <p ^ (t) for values of 
t, modulo some number T" / where I <'X'< Nq. This 
is possible because of the interpolation feature of 
the resynthesis transformation from <p to x, as indi- 
cated in section 3.5 below. 
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3 .5 The next phase of the attribute extraction pro- 
cess treats the problem of resynthesis of an approx- 
imation to the original sensor data. In problems of 
information transmission, the effectiveness of the 
system is often measured by the fidelity with which 
this resynthesis can be achieved from the smallest 
amount of intermediate, interpreted (i.e., suitably 
encoded) data . The resynthesis process is described 
in A-1 .5 and is greatly simplified by the unitary 
property of the eigenbasis transformation . 

Basically, the inverse transformation, fromyto<5, 
and hence to x, is the transpose of the transforma- 
tion from 6 to ^. Moreover, for a given value of 
t, each9^p(t) is formed by looking ahead in the 
X data up to Nq units along t , hence in the 
resynthesis process, the estimate '^^(t) can be used 
to estimate a new x' through a process of inter- 
polation and extrapolation. Several tabular modes 
of description are outlined in A-4.6 and 4.7 and 
follow a format similar to that used for the raw x 



data, except that the intensity level of the re- 
synthesized data points is now a measure of the 
confidence that the resynthesized data points be- 
long to the signal pattern. The use of multi-level 
intensity, under program control on the color CRT, 
has proved highly effective in providing a "feel" 
for the manner in which the resynthesis process is 
altered as the "bandwidth" of the interpreted, in- 
termediate data, is compressed. 

3.6 Finally, the consequences of carrying out the 
various kinds of controlled information degradation 
cited in section 3.4 above can be examined through 
an on-line comparison of the raw sensor data, x, 
with the resynthesized approximation, x' . The 
initial efforts in this phase have been concerned 
primarily with means for conveniently obtaining a 
direct visual comparison between x and x' data. 
However, only problems of computation speed limit 
the extent to which a variety of analytical error 
criteria can be examined and compared. 



APPENDIX A 

FUNCTIONAL DESCRIPTION OF A CLASS OF 
DYNAMIC ATTRIBUTE EXTRACTION PROCEDURES 



1 . Functions to be Evaluated 



1 .0 The Basic Measurement Descriptor 



Let d (t) be the basic measurement descriptor associated with the stored measurement data 

X (t +0(ri)f defined, for a = (x, a, a^), and t, specified over suitable domains as 
a v U ' 

■o' 



S, (t) = ° '''"'' % <' " "o'- 

C if X = x^ (t + of^), 



and 



C = ] / ^Nq N^ 



N 



where £ ^ 

a = 1 



(t) = 1 



for each t . 

We shall also write 

£q (0 = S (x, or, (Xq} t), 

and, for convenience, interpret the ordered triplet (x,^, <y-^) = a as the integer, 
a = Nq N^ X + N^ ('^^o'^^ ^ ^ ' 
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where 

X, y = 0, 1 , 

a, 3 = 1, ..., N, 

N = 2 Nq Ny 

n = 1 , . . ., N, 
a, b = 1, ..., N. 

1 .1 Weighted Bivariate Interaction Matrix 
Let 

^b = <£ a^'^ 6b(^^ >' 
where 

^ <°o' ep) 

< 6^(*) Sb <*) > = N(S) 2 <Sa « <5b <*) • 

Here S in the set of values of t over which the finite averaging operation is carried out, and 

N(S) is the number of elements in S. 

We shall require that 

■"ab = ''ba' 

and that 

N 

Z F = 1 . 

. aa 

a = 1 

Hence a constraint on the function K is that 

1 N, Nq 

Z L L K (oq, Oq) = 2 Nq N^ = N 

X = a = 1 a^ = 1 

1.1.1 Unweighted Case 

(Relative interaction is a bilinear function of § -buffer is independent of <« ^^ Pa components 
of positions.) 

K {a^, ^q) = 1 

1 .1 .2 First Weighted Case 

(Relative interaction in bilinear function of a-.^ 3 _ components of positions.) 

< 



6 Pq^Nq - °o -^ ^^ % = PO 



K (qq, 3q) = (Nq + 1) (Nq + 2) 



^ (^0' °o^ % - ^0 
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1 .1 .3 Second Weighted Case 

(Relative interaction is inversely proportional to number of positions which a signal of length 
I 0n'"a^ol can occupy in S -buffer.) 

K ( ar.r Br) = 

2N, (Nq - I Po - «o I) 

1 .2 Eigenfunctions, u (a), and Eigenvalues, ^ / of F , 

n ' 'n a b 

Let 

N 

£ F u (b) = A„ u (a) , 

1 _ , ab n n n ' 

where the values A are ordered so that 

'^n " ^n + 1 
for a 1 1 n . 
Let the u's be normalized so that 

N 

L u (a) u (a) = S 

, n m nm ' 

a = 1 

for all n, m, and 

N 

E u (a) u (b) = , 

, n n ab « 

n = 1 

for all a, b. 

Thus, u will be a unitary tranformat ion . 

Note that 

N N 

A„ = S Z F . u (a) u^ (b) ^ 0, 

n 111 oo n n 

a = 1 b = 1 

for each n, and that 

N N 

r > = S F = 1; 

, '*n , aa 

n = 1 a = 1 

hence, for each n 

^ A ^ 1 . 
*n 

1 .3 Transformation to Interpreted Descriptor, ^ (t) 

Let <^ (t) be related to ^ (t) by the transformation 
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N 

4> (0 = S u^ (a) 5 (t) . 

a = 1 

Note that 

« N N 

4n (^) = ^ ^ "n (°) "n (b) c^ (t) S . (0 

a = 1 b = 1 



hence 



N N 

n = 1 a = I 



N 



for all 


t. 












Also, ' 


we 


may 


note 


that 








< 


4>' 

T n 


(t) 


> = 


a 


N 
N 



= 1 b = 1 "" ^^ 

N 

L F . u (a) u (b) = X . 

, I . ab n n n 

a = 1 b = 1 

The inverse transformation, since u (a) is unitary, will be 

t (t) = E u (a) >, (t) = 6„ (0 

a , n I n a 

n = 1 

where 6 (t), as given by the summation, will, in general, only be an approximation to the de- 
scriptor X" (t), which must, by definition, be or C for each a and t. 

Hence, for pusposes of estimating o '" the presence of errors, we may take it to be C if 
O > 0.5 C and otherwise. A final check on the validity of the estimation will be the re- 
quirement that 

CK = E 5^ (t) = 1 , 
a 

for all t. 
1 .4 Re interpretation of Data Descriptors, ^ (t), by Partial Elimination and Reconstruction 

Let the vector c^ (t) be subjected to a transformation to new data <j> ' (t), where 

i<p (t) for 1 = n = m, 
" m f < < M 

z (t) for m n = N. 

Here the synthesized data, z (t), may either be deterministic or nondetermin|#ic data, 
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subject to the constraint |z (t) | =1 for all n, t. 

1 .5 Resynthesis of Basic Measurement Data from Reinterpreted Data 
Let 

S ' (t) = E " (°) ' (0. 

a i, n n 

n = 1 

where, by definition, we take the resynthesized raw data x' (t) to be 

x' (t +«q) = X if g' = 0.5 C. 
This gives a prediction for up to N^ units beyond t. 
Note that c , suitably quantized, may be taken as the measure of confidence we have in the 



decision: 
x' 



a (t + qtq) = X, 




for a given «, ctq , t . 

For resynthesis basedondata always measured relative to the centeiof the storage N-j + 1 along 
the time-like storage coordinate a-., 2 

2. External Parameters and Functions 

2.1 Input Data, x (t) 

Binary valued range, {0, 1 } , for x; 

Integer valued domain, { 1, ..., T + N-. } , for t; 

Integer valued parameter set, { 1, . . ./ N. j , for <y. 

2.2 Synthesized Data, z (t) 

Continuous range of values in closed interval, [ -1, 1 ] , for z; 

Integer valued domain, /" 1, ..,, T + N^ }« for *"; 

Integer valued parameters set, {m + 1, ..., N ] , for n; 

Values of z (t) will be specified in both a deterministic manner and also statistically. 

3.0 Internal Parameters and Functions 

3.1 Length of Transient Data Storage, N-., where N-. isodd. (Required for center of storage 

K.I J. 1 

to be at an integer value _0 ), for parameter^ . 

2 
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3.2 
3.3 
3.4 
3.5 
3.6 



4.0 
4.1 



Total Size of Transient Data Storage N = 2 

Span of Transformed Data, N. 

Restricted Span of Transformed Data, m. 

Matrix for Eigenf unction Transformation, F , . 

ab 

interpreted Descriptor, <p (t) 

Continuous range of values in interval [ -1, 1 

Integer valued domain [ 1, ..., T ] for t; 

Integer valued domain { 1, ..., Nj for n . 

Format 



•^0^1 



Matrix Fab 



X = 
or/3 1 2 

2 



X = 1 
N, <y/p 1 2 .. 



N, 



= 1' Po = 



N, 



N, 



X = 

c^^ 1 2 

1 

2 



N. 



= 1 



a/0 
1 
2 



.. N. 



°0 = Nq, Pq = Nq 



N, 



N, 
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4,2 EigenfuncHons and Eigenvalues 



u 



No — % 





No 






No - 


4.3 


Raw Data, 
t/« 


X (t) 
~ Of — 

1 


2 


Nl 




1 


X 


X 


X 




2 


X 


X 


X 



X. 



1 1 

X = X = 1 

oTq/* 1 2 ... N^ ot^/ot 1 2 ... N^ 



X 



X = X = 1 

«Q/a 1 2 ... N^ (VqA 1 2 ... N^ 



T X X X 

NOTE: Value of Symbol to be 

X Recorded 

Blank 

1 Asterisk 
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4.4 Interpreted Data, <|) (t) 

t/n 1 2 ... N 



T 

NOTE: Data is specified to one decimal digit plus sign. 

4.5 Reinterpreted Data, (^ ' (t) 

Same as in 4.4) 

A Nq + 1 

4.6 Resynthesized Characteristic Function, o' (x, a, = ; t) 

Essentially same format as in 4.3 except for type of symbols) 
t/a 1 2 ... N. 



1 



T 






NOTE: 

Value of ^ 




Symbol to be 
Recorded 


S <0.25 C 




Blank 


0.25 C < ft < 0.5 


C 


Minus Sign 


0.5 C < ^ < 0.75 C 


Plus Sign 


0.75 C < S 




Asterisk 
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4.7 Resynthesized Characteristic Function, o' (x, oi, ^^^ ; t) 



'a 1 2 ... N. 



1 
1 t = K CK = 



No — 

1 t = NQ+K CK = 



^0 



1 T = JNq+K CK 



No — 

where J, K are positive integers such that 
J Nq + K < T . 
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Section III 
HARDWARE AND INPUT-OUTPUT TECHNIQUES 



FILM READING USING A COMPUTER 
A.M. CappelletH 



Abstract 



The advantages of using movie film as a med- 
ium for recording and storing data, which 
might be produced by a space vehicle, or by 
a wind or current measuring device, are quite 
impressive, particularly in view of the limit- 
ed storage space and input power required. 
The main problem is devising a means to 
"read" the data after it has been recorded^ 
Because of certain inevitable fluctuations of 
the film, simple mechanical and electrical 
devices used for this purpose were found to 
be unsatisfactory. In order to enlist the aid 
of a computer, it was necessary to develop 
a suitably sophisticated light-sensitive input 
device, optimal logic systems and appropri- 
ate programs. 

Introduction 

Scientists over the past 50 years or so have often 
found it advantageous to use 16mm and 35 mm film 
as a mediumof data storage. Until recently, how- 
ever, the only methods of retrieving this data in- 
volved manual procedures and the human eye. 
Many and varied mechanical electrical devices 
have been designed for this task, but in general, 
they were proved not to be adequate . The reasons 
were obvious to those who tried to make such de- 
vices and it is generally agreed that a machine with 
the sophisticated logical capabilities of a digital 
computer would be required for retrieving data 
stored on film. 



Binary Film 

Data film can be categorized as binary film or an- 
alog film. Binary type film may be depicted by first 
describing an instrument that produces such data . 
The Richardson Oceanographic Transducer, other- 
wise known as a current meter, is a cylindrical 
shaped instrument about three feet high and eight 
inches in diameter made of very strong cast alumin- 
um built to withstand the immense pressures of the 
ocean depths. On top of this instrument is a vane 
which functions much the same as a weather vane. 
Within the instrument the direction of this vane is 
converted across the film into fourteen gray binary 
bit positions, called channels. On the bottom of 



the current meter there is what is called a Savon ios 
rotor which functions like a wind anemometer that 
measures the speed of the current. This measure- 
ment is recorded as pulses in one or both of two 
channel positions. There isalso a channel position 
for a clock pulse, and another for a continuous 
reference line which is always "on." Thus, across 
the width of the film is a total of 18 on-off channel 
positions somewhat analogous to the eight channels 
on PDP-1 punched tape. This binary type film can 
be read by straightforward procedures using logic 
and memory tables to keep track of the eighteen 
channel positions, which may vary as much as one 
tenth the width of the film. We are presently de- 
signing a system which will allow 10'2 binary bits 
on a 100 foot roll of 16 mm film. 

Analog Film 

Analog film is completely different from binary 
film, especially in the reading process. In its most 
general sense, analog film is simply a picture of 
something; e.g., aradarscope trace, a microscope 
slide, or perhaps an x-ray of human lungs. The 
process of "reading" these pictures amounts to var- 
ious levels of pattern recognition. 

The Film Reading System 

Information International, Inc. has recently com- 
pleted the development of a film reading system 
suitable for reading both binary and analog film. 
The film reading system is based on three major 
elements: a PDP-1 digital computer, together with 
a visual display scope; a film reading device; and 
computer programs for using the computer and film 
reader. 

The film reading process involves the scanning of 
film by a rapidly moving light point on the visual 
display scope. The output of this scanning opera- 
tion is detected by a photo-sensitive device in the 
film reader and relayed to the digital computer for 
further processing and analysis. In addition to 
translating the data itself into a more desirable 
format, the film reading system can also furnish 
summaries and analyses of the data as may be re- 
quired. 
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The flexibility of the film reading system in two 
respects should be emphasized . First, almost any 
formatof data on film can be read, with appropriate 
modifications to the basic computer program. This 
includes data represented in the form of lines, graphs 
(e.g., radar pulses), points, and other similar forms 
of data. Second, almost any type of desired out- 
put may be obtained once the basic data is obtained 
from the film. Forms of output which ore available 
include the following: 

1 . A print-out or listing of data on paper 

2, A record of the data on magnetic tape 

3. Visual representations of data . These may 
take the form of a continuous graph (using 
adigital x-y plotting device) . Orthey may 
take the form of photographs — still or mo- 
tion — of scope displays . This latter format 
is particularly flexible In that computer 
programs may be designed and written to 
provide many types of useful and informative 
data representations. 

In addition to data recorded on film, data recorded 
on any light-permeable medium (such as light or 
medium weight paper) can also be read by means of 
the film reading system. 

Applicationsof the film reading system include the 
following: 

1. Analysis of data produced by oscillographs 
or other types of graphic recorders 



2. Tracking and analysis of objects for which 
motion pictures are available (e.g., missile 
tracking studies) 

3. Reading of astronomical orastrophysical data 
recorded on film (e.g., analysis of stellar 
configurations) 

4. Reading photographs of cloud chambers, 
bubble chambers, and spark chambers 

5. Counting of particles (such as blood eel Is or 
bacteria) in photographs 

Reading of Analog Film 

A film reading system to read analog data repre- 
senting missile tracking studies recorded in the form 
of radar pulses on 35 mm film was completed. The 
film reading system was developed with the follow- 
ing capabilities: 

1 . Approximately 500 readings per frame of the 
amplitude of the radar signals 

2. Computation of the median amplitude volue 
for each frame 

3. Count of the number of radar pulses 

4. For each radar pulse, a measurement of pulse 
width, overage amplitude during the pulse, 
and measurement of the location of the 
leading edge of the pulse 

5. Recording on magnetic tape of all original 
and processed data 
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A FUNCTIONAL DESCRIPTION OF THE ITEK DISPLAY SYSTEM 
Earle W. Pughe, Jr. 



Abstract 

The Itek-Flicker Free Display displays line 
drawings on a 10" x 10" scope 30 times a 
second with a maximum total line length of 
600 inches. The Display is controlled from 
a Telex disc through logic which controls 
the beam. There are about 20 instructions 
used to control the display. When the dis- 
play is to be changed, new instructions are 
put on the disc by a block transfer from the 
PDP, otherwise the computer is not needed 
for the display. 

Introduction 

In the development of the Electronic Drafting Ma- 
chine (EDM), sometimes referred to as the Digital 
Graphic Processor (DGP), the need for a suitable 
real-time input-output computer display was im- 
mediatelyapparent. Amechanical X-Yplotter was 
deemed too slow. A conventional point by point 
computer display has objectionable flickerand con- 
sumes a substantial amount of computer time when 
displaying several hundred inches of lines. Thus 
there was a need for a flicker-free real-time dis- 
play thatdid not require appreciable computer time 
to operate and which could display a meaningful 
drawing while accepting a light pen input as the 
drafting pencil. 

Requirements 

To meet the flicker-free requirement a frame rate 
of 30 per second was selected. This rate is com- 
patible with a conventional 1800 RPM drum or disc, 
the same as TV frame frequency and close to the 16 
frame or 32 fields per second of home movies. If a 
higher frame rate is used, the amount of display is 
correspondingly reduced. Conversely, reducing the 
frame rate would enable more data to be displayed; 
but the flicker would become very apparent and , 
objectionable. 

Todisplaya useful amountof data, i.e., more than 
500 inches of lines on a 10" x 10" display area at 
30 cycles, a point by point display is too slow and 
a faster scan such as TV, requires too many bits of 
storage, so a continuous incremental line drawing 



technique was selected. The basic method employ- 
ed is to specify the initial X Y position and then 
to leave the beam on and give incremental values 
of A X and AY which are added to the current X Y 
each increment of time. Thus a line drawing tech- 
nique much like that used on many mechanical X-Y 
plotters is used. 

A 2 or 1024 position scope such as the DEC Type 
30B is used with the normal increment being 4 
adjacentpositionsorapproximately 1/25 inch. The 
period is 1 . 67 x 1 0"° seconds, i.e., 20, 000 incre- 
ments for 1/30 second, giving 800 linear inches of 
drawing. Certain bookkeeping functions tend to re- 
duce the 800 inches in a 1/1 scale. However, 
scales of 1/4, 1/2, 1, 2, 4, 8, and 16 are avail- 
able so several thousand linear inches may be dis- 
played. On a 10" x 10" display, 1000 inches of 
drawing represents 10 lines per inch across the face 
of the scope; an amount far in excess of any usual 
line drawing. About 2000 characters can be dis- 
played on the scope, which gives the display sys- 
tem use as an editing tool. 

Block Transfer 

To meet the problem of releasing the computer for 
other uses when the display is not changing, the 
display data is blocked onto a drum or disc in 6-bit 
parallel from the computers' core memory. A special 
1-0 order (720061) has been added to the PDP-1 at 
Itek and to one PDP-1 at AFCRL to block transfer 
the data from the core memory onto the disc or drum , 
or to read the data back into the core memory from 
the drum. Since 20,000 bits per track for 6 tracks 
in parallel represents almost 7000 words, several 
blocks are required to fill up the drums display 
tracks. A special feature of the block transfer is 
that no extra counters are needed. If the block 
order is given in register n, registers n+1 through 
the end of memory are blocked on the drum (or read 
from the drum), the program counter end carry ter- 
minates the order and the next order is taken from 
register zero. Thus, a typical transfer would be: 

n-1, 220010 register 10 contains the drum address 
n, 720061 



bl 



n+.. 



7711 



] 



display data 



601000 jump to next computer routine 

When it is desired to use the computer display to per- 
form such functions as tracking the light pen or dis- 
playing control points, the computer display oper- 
ates in the normal way and takes precedence over 
the drum display. When the computer display is 
done, the drum display continues with that portion 
of the picture erased which would have been dis- 
played at the time of the computer display. Two 
techniques are available to the programmer to keep 
the computer display from apparently interfering 
with the drum display: one is to display from the 
computer at a time allotted for this purpose on the 
drum, and the second is to erase a different portion 
of the display each time. 

Display Processor 

A block diagram of the system is given in Figure 1 . 
The computer blocks the display information onto 
the drum. Between the drum and the display CRT 
is a display processor. The function of the display 
processor is to decode the 6-bitdisplay instruction, 
perform the necessary arithmetic to calculate the 
new X-Y position and to transfer this information 
into the X and Y decoder registers in the display 
console. The display processor is a small special 
purpose computer. The 6-bit display byte is de- 
coded as an instruction which in turn, with seven 
timing pulses, controls the X accumulator and Y 



accumulator. The 6-bit display byte is not added 
directly to the X and Y accumulators. There are 
codes forsuch functions as ignore, beam intensity, 
point plot etc. 

In the display processor there is a drum sector counter 
(20 sectors) and 8-bit segment counter. The sector 
counter is cleared by the drum index pulse and 
counts the 20 drum sectors as the drum revolves . 
The programmer can number each line or character 
by giving a segment command at the start of each 
pulse. The sector pulses clear the segment counter . 

Light Pen Response 

If it is desired to use the light pen to select a line 
or character displayed from the drum, the segment- 
sector counter is read into the computer when the 
light pen sets its flag. Each line is given a segment 
count by the programmer before blocking the display 
data onto the drum and this data is transferred onto 
the drum along with the picture. The light pen re- 
sponse is well underone microsecond so no ambiguity 
resu I ts . 

While the display system was designed for the Elec- 
tronic Drafting Machine, it has general use as a 
computer output device. At Itek the display has 
beenextensively usedas the output for lens design' 
and has been used to a lesser extent as an alpha- 
numeric display. 



1 See paper by Shannon, Morel lo, Rimmer and 
Radkowski - "Use of Displays in Optical Design." 
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A TIME-SHARING SYSTEM FOR THE PDP-1 COMPUTER * 
John E. Yates 



Abstract 

A system for time sharing of the PDP- 1 digital 
computerwith seven typewriters, two paper 
tape punches, two paper tape readers and two 
CRT Displays is described. The additional 
hardware requi red forthe system and the mod- 
ification required to a basic PDP-1 are de- 
scribed and a program is presented to handle 
the monitor of "executive" functions of the 
system. A System using two typewriters, one 
punch, one reader and one display based on 
this design is currently being installed at 
M.I.T. 

Introduction 

A time sharing system for the PDP-1 at M.I.T. has 
been designed and is in the process of construction. 
It allows for the use of seven typewriters, two paper 
tape punches, two readers, and two CRT displays 
simultaneously, by up to seven users. Every effort 
has been made to make as many features of the bas- 
ic machine available to users as possible, although 
some sacrifices must be made to make the computing 
capacity available to several users simultaneously. 

The System 

The seven consoles which comprise the system each 
consist of a typewriter, six sense switches, a con- 
so I e ON switch, a display lever which allows 
lengthened quantas, a debugging button, and two 
lights indicating the console is active in core and 
it is permissible to type in. The two punches, two 
readers and two displays are shared among the users 
on an assigned basis. The test word switches are 
also assigned. 



Programming for the System in Two Parts 
The programming for the time-sharing system con- 
sists of two parts, the executive routine and the ad- 
ministrative routine. The executive routine is a 
permanent part of core memory (approximately 512 
registers) which will handle the needs of the time 
sharing system on a second-to-second basis . It wi 1 1 
handle the so-called instruction traps and time-out 
interrupts. 2. The administrative routine is a sep- 
arate program brought into memory on request to 



perform such jobs as: assignment of equipment, reg- 
ulation of memory protection, provision for services 
such as an assembling, debugging routines, editing 
programs, error indication for illegal instructions, 
and other miscellaneous jobs. Let us assume several 
users are using the computer, a particular program 
is in core and is being executed. Since one does 
not wish the computer to stop because of a user's 
errors, (and thus keep others from executing) certain 
provisions must be made. All halt instructions, il- 
legal operation codes, requests for manual run, and 
illegal instruction cause a trap to the executive 
routine, ER (See Figure 1). 



Trap 
Dispatch 



Traps 



Service 
External 
Equipment 



Store c haracter 
in buffer or 
get from buffer 



Handle 
Equipment 
Assignments 





Set up Dismiss 




Figure 1 General Flow 
Diagram of Executive Routine 

Similarly certain lOT commands must trap as the 
program does not know if the equipment has been 
assigned to it, or which one to address if one has 
been assigned. The ER then executes the command 
using the correct assignment, or puts out an error 
indication thru the administrative routine 
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Maximum Efficiency 

The program may wel I compute or require characters 
faster than the I/O equipment can take care of or 
supply them. Normally, the computer waits in an 
in-out halt for the completion pulse before process- 
ing the next character. Under the time-sharing sys- 
tem it goes to another program while waiting. For 
maximum efficiency, several characters are com- 
puted at once and stored in a buffer in the ER. Then 
the next program is brought in. At frequent intervals 
a time-out interrupt occurs where in control is mo- 
mentarily transferred to the ER. Here one character 
is taken from each bufferand transmitted, if the I/O 
device is ready to accept. If not, it is skipped. 
Control then returns to the program in core. When 
a certain maximum time has elapsed, or if the ER 
buffer becomes full, or if the program runs into an 
error, the program is dismissed and another brought 
in. A magnetic drum capable of holding twenty - 
two memories is used as auxiliary storage for the 
programs not currently active in core. In this way 



no time is wasted and each user's program is in mem- 
ory often enough for the user to think he has the 
computer to himself. 

Several instructions have been added to the machine 
which are valid during the time the executive rou- 
tine has control . They are decoded from the lOT 
11 class and are used by the executive routine to 
test the states of the consoles, to make equipment 
assignments, and to provide the proper information 
to the status bits for the user current in memory. 

*This paper is based on a thesis prepared by the 
author in partial fulfillment of the requirements for 
the degreeof MS in Electrical Engineering, M.I.T . 
The complete thesis is avai lable as report ESL-R-140 
from: 

Publications Department 

Electronic Systems Laboratory 

Building 32 

Massachusetts Institute of Technology 
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PROCESS CONTROL APPLICATIONS OF PDP-4* 
C. G. Bell 



Abstract 

The PDP-4 is designed to operate as a mod- 
ule for a large majority of process control 
applications. Intermsof these applications 
the interface capabilitiesallow PDP-4 to be 
connected to the process, or to Input/Output 
equipments, with a minimum amount of extra 
hardware in a relatively straightforward 
manner. 

The PDP-4 configuration, in terms of the 
above design constraints is described as well 
as the specific interface terminals, their po- 
larities, timing and operation with the pro- 
gram. The terminals include Device Selec- 
tion, Information Collection, Information 
Distribution, Program Interrupt, Data Inter- 
rupt and Real-Time Clock. 

*The Editor regrets that the complete paper was not 
received in time to be included in these proceed- 
ings. 

The PDP-4 data processor was introduced at the 
May 17 meeting. Users of this processor were for- 
mally welcomed at the DECUS Annual Meeting in 
October, 1962. Future plans by DECUS Executive 
Board include a special meeting in 1963 for PDP-4 
users . 
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Section IV 



PANEL DISCUSSION 



MACRO, DECAL, and the PDP-1 

Moderator: Dr. John Hayes* 

Panel : (MACRO) Professor Jack Dennis, M.I .T. 

Harrison Morse, DEC 
Alan Kotok, M.I.T. 

(DECAL) Edward Fredkin, Information International, Inc. 
Ted Strollo, BBN 
Roland Silver, Mitre Corp. (not present) 



Dr. Hayes: For some time now, there have been rumblings among programmers about DECAL 

versus MACRO for the PDP-1 . It began to look as though perhaps people 
wouldn't talk to each other who talked different programming languages. From 
the discussion today, we should learn a good deal about both of these program- 
ming languages. 

Among a numberof things, I'd like to remind our pane lists that some of us know 
DECAL, some of us know MACRO, some of us don't know either. But very 
few of us know both MACRO and DECAL. So, I hope that statements may be 
explained where there maybe a language difficulty. In the process of discus- 
sion, I would hope that we would develop first of all, for the purpose of new 
users who are perhaps trying to decide which language to use, the relative 
advantages of one over the other or perhaps the relative advantages of using 
both. For old users of MACRO or DECAL, such as the members of my labora- 
tory, we would like to find out enough advantages of one language over the 
other to justify the time and expense (which may well be considerable) of re- 
training people to use the other language. 

Now I'd like to introduce the panel: For MACRO, Professor Jack Dennis of 
M.I.T., Harrison Morse of DEC, and Alan Kotok of DEC and M.I.T. For 
DECAL, Ted Strollo of AFCRL and BBN, and Edward Fredkin of Information 
International, Inc. I'm sorry that Roland Silver, who was to speak for DECAL 
could not attend. I am moderator, but I plan to moderate only in the case of 
severe physical danger to one or more participants. Professor Dennis. 

Prof. Dennis: Am I correct in the understanding that so far in this meeting, there has been 

no presentation of MACRO? How much time do I have for my initial presen- 
tation? 

Dr. Hayes: The time will be five minutes. 

Prof. Dennis; I will startwith a brief description of what MACRO is. MACRO is an assembly 

program (as opposed to a compiler program) and was originally developed in 
1958 and 1959 for the TX-O computer at M.I .T. The needs of the users of the 
TX-O computer, at that time, were the determinants of the features that were 
placed in the MACRO assembly program. The original version of the MACRO 



*Psychologist, Operational Applications Laboratory, Air Force Electronics Systems Division, AFSC, 
Bedford, Mass. 
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assemblyprogram was based quite a bit on previous experience in the Whirlwind 
LaboratoryatM.I .T. and the experience of the people who participated in the 
Whirlwind group. When the TX-O computer was brought to M.I .T. in 1958, 
we had need for creating a new programming system for the machine . At that 
time, we asked for an assembly language so that the machine could be used by 
students and research people at M.I.T. We discovered many features which 
should be in an assembly program for the type of uses which were being made 
of it - for example, the automatic macro-instruction feature, whereby a user 
may assign a name to a sequence of instructions or words and later on in his 
program use that name to specify the sequence to be placed in the object pro- 
gram. Since then additional features have been added to TX-O MACRO, such 
as automatic reservation of storage for constants, for variable automatic stor- 
age, and automatic reservation of table space by using a dimension statement. 
Various people here helped with this work. Among them, we should mention 
Bob Saunders in particular (now with Information International), Bob Wagner 
who is working for the Rand Corporation, and Alan Kotok who is on this panel . 
When the PDP Computer was donated to M.I.T. bythe Digital Equipment Cor- 
poration in the fall of 1961, there was quite a bit of concern about the kind 
of language that should be provided for the PDP for use by students and staff 
in the M.I .T. work and after some time we decided to translate the MACRO 
program so it could be used on the PDP. This was a rather easy job because 
of the great similarity of the two machines, and I believe it was accomplished 
in something like three weeks of work on the part of about four people, work- 
ing part time, which was quite an accomplishment. As to the reasons I think 
that MACRO is a very useful assembly program, I have the feeling that for the 
PDP Computer, an assembler is more desirable than a compiler, I feel this way 
because applications made of the PDP-1 are such that using a compiler would 
lead to object programs which are relatively inefficient and require consider- 
ably more space than required by a program hand-coded for translation by an 
assembly program. When I say this, I don't mean that a compiler can't be con- 
structed which would be suitable for the PDP-1, but I believe that compilers 
which are based on the kind of compiling techniques which are now in exist- 
ence would lead toprograms which are long and time-consuming in their opera- 
tion on this machine. So my feeling is that for many classes of problems for 
which the PDP is used, an assembly language is the more important language 
to be concerned with. I believe that the MACRO source language has all of 
the more important useful features of any assembly language in existence and 
is very flexible in its use. I think I'll wait until later for any further comments. 

Dr. Hayes: Maybe we should now turn to a DECAL representative: Mr. Fredkin. 

Mr, Fredkin: Well, I guess I've been labeled a DECAL representative . Let me say some- 

thing about MACRO, though. I like MACRO and I think it's fine, but I don't 
think it's fine for the PDP-1 because I don't think the PDP cares what you put 
in the reader as long as you don't make it shudder too much. I think MACRO 
is fine for a group of people and there are members of that group here . The 
fact is, that we could be sitting up here arguing whether we should speak English 
or some other language and I don't think you can argue this on the merits of the 
language so much as by looking at the language in terms of its practical uses. 
DECAL and MACRO are two very different languages. DECAL is a very com- 
plicated system, MACRO is a simple system. Simplicity is very nice sometimes 
and the PDP-1 is perhaps a simple computer, but if you describe the two sys- 
tems by listing their properties, DECAL includes more of the desirable features 
of MACRO than vice versa by a big margin . 
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1 . DECAL has one important thing and this is really best described as growth 
potential. The language is increasing in capability with time. The fact that 
it's changing may be a disadvantage, but still it is including more and hiore of 
the ALGOL language features. 

2. DECAL has a library feature. It allows groups, large organizations to set 
upsystems with various individuals' programs. It allows you to use library pro- 
grams and library tapes and allows you to relocate binary - in general, those 
things that are oriented for systems programming. 

Now MACRO, on the other hand, is a beautiful language for one person who 
wants to sit down, write his program, and make it work. This is characteristic 
of many users of MACRO; in particular, I would say, characteristic of M.I .T. 
students who generally don't get together to write large systems, but write their 
own programs. They want to assemble, get something out, run it, debug it, etc. 
That is very different from the way many other organizations use computers. 
So, I realJy-feel that there are a set of users for which MACRO is better. On 
the other hand, I feel that there is a much largerset for which DECAL is better 
because most organizations have invested in systems and these systems are large 
and quantitative . 

Another point. . .Sure enough, MACRO does result in efficient object codes, 
butnormally I don't care. What I care about isthe lapse of time between when 
I start writing and when I have a finished program. Generally I'm going to 
write the program over five times and maybe the last time I'll do it in machine 
code. I want the amount of time I spend doing this to be minimum; I don't care 
about the machine. I usually write programs for hours that only amount to 
milliseconds and so sometimes it takes 10 milliseconds (instead of one) for hav- 
ing used the DECAL algebraic compiler. On the other hand, use of the DECAL 
compiler may cut hoursoff the time of actually writing the program itself. So, 
I think that there are very specific issues involved in the choice of a program- 
ming language, and I think I'll defer getting down to them until we've heard 
from each of the people . 

Mr. Kotok: I don't think I can say as much as the two gentlemen who preceded me, but I 

think they did outline the issues pretty well. One thought, which might be 
germane, is that maybe we shouldn't be arguing whether MACRO versus DECAL. 
Instead, whether either one of them or FRAP. It seems I've been informed that 
a large number of users are still using FRAP for one reason or another and may- 
be if we come out no where else, at least users will know something about one 
of these two systems that we are discussing here . 

I'm certainly not trying to claim that MACRO isas general a system as DECAL, 
especially, the new DECAL described in the paper that was presented before 
this discussion.* I think that you obtain through this generality, the facility 
of the use of DECAL (as was shown in the discussion that preceded this one) 
the description of instruction generators and action operators, which caused 
Mr. McQuillin to indicate that even he gets confused occasionally. The 
macro-instruction feature of MACRO is somewhat akin to the instruction gen- 
erator feature of DECAL and our system is, we think, somewhat easier to use. 
I think that most of the complaints against MACRO and why people say DECAL 

*DECAL-BBN - Symbolic Version of DECAL - by R. J. McQuillin - p. 19 of these proceedings. 
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over MACRO as an assembler is that, first of all, MACRO has a limited 
set of symbols: 1,2, and 3 characters. I can certainly see that people 
can get unhappy with this. Maybe I'm on the wrong side of the fence, too, 
but, like Ed, I can see where there might be objection to this. Also, in 
MACRO there is an absence of a linking facility between programs. However, 
the linking facility, it seems, as provided by DECAL, is a mixed blessing. 
Since it is a one pass system, there is no way to directly get a loadable binary 
type which can be read in right away. The second pass of the assembly that 
MACRO does do is often necessary in DECAL if you do wish just a self-loading 
tape causing you to go through two passes of punching. These are just a few 
of the points . 

Mr. Strollo: I'd like to say that I don't think it's different typesof programmers who should 

use MACRO or DECAL. It would seem to me it depended on the type of pro- 
gram to be written . Sometimes when writing a short program which one would 
like to get into the machine as quickly as possible, MACRO has advantages. 
But, if one were working on a long system and expected to link several short 
programs together then I think DECAL is the better system to use because pro- 
grams which other people have already written can easily be incorporated. A 
library tape, for example, could be used. Thus available programs which have 
already been debugged can be linked with the recently written program. Cer- 
tainly this is a lot easier than recompiling all programs over again and going 
through a new process with each program and then reading it into the computer. 

I think there are two philosophies you can have when writing programs. You 
can either write one very large program (and you would almost have to do it 
with MACRO where all the symbols are linked together and where you stand 
a good chance of not getting the program debugged for quite a while) or you 
can write several short programs debugging each program as you write it . When 
you are certain that programs A&B are working, then you can write a program 
C and get it working and then try it in conjunction with A and B. I think the 
latter is a strong point of DECAL. You can take all of your shorter programs 
which you know are working now and link them together with your recently 
written program and be pretty much certain that you're not going to have a 
major debugging problem. 

Mr. Morse: I would like, first of all, to make one thing very clear. An impression, I 

think, Ed Fredkin and Ted Strollo have given is that it's difficult for more than 
one person to work on one program in MACRO and it's difficult to write a pro- 
gram that isn't one big chunk of coding. This is not true. I have many times 
written programs which consist of a big glob of subroutines (literally 20 or 40 
to 100) and a large control program, with the subroutines on separate symbolic 
tapes. The subroutines are assembled and checked out separately, prior to put- 
ting together the whole system. Once the subroutines are checked out, these 
are punched out on a binary tape and a symbol punch gotten from MACRO. The 
subroutines sit in a fixed place and remain there while you go to work on a 
control program. One great advantage of this is that you can use MACRO 
instructions as a means of calling these subroutines. In particular, one person 
can write all the subroutines, define how they're used, and another person, not 
knowing a thing about this big black box, can use MACRO instructions to call 
the subroutines. This is one way of performing the same function that DECAL 
does with the relocatable subroutines which are called by systerfn symbols when 
the main program is loaded . Just this to counteract the impression that MACRO 
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is for one-man programs only. There are advantages to both systems. If you're 
doing mainly arithmetic processing, DECAL does have the advantage that you 
can write a program much more quickly and possibly get it debugged much more 
quickly. A disadvantage here is that at the present time DECAL's programs 
must be debugged in octal . This will eventually be counteracted by using DDT 
and symbols from DECAL for debugging . Another disadvantage is that if the 
DECAL program is large and has many systems symbols which must be stored in 
memory while loading the program, then you also have storage problems that 
are alleviated by using MACRO since you can use all of core except the last 
27 registers or so. 

Mr. Strollo: If I understand MACRO correctly all symbols are three characters in MACRO. 

Is that correct? For example if someone else were working on a program could 
you say to them don't use the symbol A because I'm using the symbol A in my 
program and you can't use it in yours? Is this what you would have to do? I 
think there should be a feature for externa I symbols because there are a certain 
group of symbols that I use over and over again in several of my programs and 
even if I were working on a system I like to use these symbols within the pro- 
gram like "move" or something like that. 

I think the communications problem when you're writing a long system would 
be enormous if you had to eliminate all the symbols you use and pass it on and 
say don't use these symbols in your program. 

Mr. Fredkin: Well, when writing with FRAP we used to break things up. We used to say 

I'll start all my symbols with my initials. This is sort of hard when you're lim- 
ited to three characters because it doesn't leave too many initials. 

Dr. Hayes: Especially if you have a long name. 

Mr. Fredkin: That's right. If you have four initials. 

Prof. Dennis: Take the example that Mr. Morse gave in which you compile a set of subrou- 

tines and then define a set of MACRO instructions to be the calling sequences 
for the subroutines. After you've got to that stage, you may dispense with the 
symbols which are involved in the subroutines and simply use the MACRO in- 
structions in your main control program. So once you have coded the subrou- 
tines and defined the calling sequences and debugged them you may dispense 
with all of the symbols involved in these programs in the subroutines and refer 
to them only through the MACRO instructions. 

Mr. Fredkin: Isn't that true only if you know the binary locations? 

Prof. Dennis: No . 

Mr. Fredkin: Dispensing with all the symbols? 

Prof. Dennis: One wayof doing this is to define the calling sequences as macro-instructions 

on a separate tape which is assembled with the subroutines. Then a definitions 
tape is obtained containing only the macro-definitions. If you have used the 
system correctly, the macro-instructions defined on the tape provide the 
correct calling sequences for the subroutines, but the tape will not have any 
of the symbol definitions of the subroutines. 
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Mr. Fredkin: However, these subroutines will not be able to link if you get rid of their def- 

initions, unless you pick the binary location. 

Prof. Dennis: That is correct. 

Mr. Fredkin: Now for instance on a DECAL library tape you might have 20,000 instructions 

worth of program. You can't fix the binary locations and pick any subset so 
it's impossible to have such facility in MACRO where you do in DECAL. By 
the way, when we to Ik about librarytape I thought I'd mention one thing. One 
of the advantages of MACRO is the ease of tape handling. With DECAL, es- 
pecially with this librarytape andsuch, we had in mind from the very beginning 
that this should be a magnetic tape feature eventually. It should work with 
paper tape, and inaddition it should get into magnetic tape. Itison magnetic 
tape here and there are people who put in a little paper tape, maybe about 20 
fanfolds, where they crowd a whole slew of things in the library and just go 
whizzing through this mag tape and they pick up all of these routines so that 
you do get access easily in a relocatable form. 

Prof. Dennis: I would I ike to point out that for the TX-O computer there is a relocating ver- 

sion of MACRO assembly program. The relocating features were not translated 
into the P DP version because of space limitations in memory of the PDP. How- 
ever, I expect that this is something that the Digital Equipment Company would 
be interested in doing, but we don't have the manpower at this time. 

Another way, is to store the symbolic version of each subroutine on tape and 
add to MACRO a facility which could be done with about as much trouble as 
putting in the DECAL library tape to call the subroutines wanted in symbolic, 
assembling these at that time . This means a double tape handling, but when 
you're handling magnetic tape the extra time needed is still so much less than 
the time used to handle the paper tape it becomes a very workable scheme and 
does not entail large changes to the MACRO system itself. 

Mr. Kotok: Just to comment on the thing Prof. Dennis was talking about before - assembl- 

ing a large number of subroutines and using the MACRO instructions with these 
subroutines as calling sequences may be done by using the symbol punch facility 
in MACRO. The symbols may be punched for use with DDT, or the MACRO 
instructions without the symbols may be punched for use at a later date. The 
MACRO calling sequences would be absolute addresses of the subroutines for 
later use . 

Mr. Fredkin: Three things occur to me: First, how about the length of symbols because we 

can't name everything you want with three letters? Second, what about re^ 
location? Third, what about library tapes? These are all features of DECAL 
now and they could be a part of MACRO. 

Dr. Hayes: Yes, our discussion seems to have boiled down to the properties of future pro- 

grams. Are there any further comments from the panel or is it now time to 
entertain questions from the floor? 

Note: (Questions from the audience were not audible for purposes of recording them. 

One question to Dit prompted the explanation of macro-instructions.) 

Mr. Morse: I would like to give a brief description of how to use macro-instructions. The 
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Mrs. Newman; 

Mr. Morse: 
Prof. Dennis: 



macro -instruct ion facility is a way of naming a series of instructions which are 
commonly used in the program, which can be put in the program by writing the 
name of the macro-instruction . 

For instance to define the MACRO instruction load: 

define load B, A 

lac (A 
dac B 
terminate 

This MACRO instruction is commonly used to load register B with the constant A. 

Now to use the instruction in the program to load 3 with register zzz one need 
only write: 

load zzz, 3 

I may also use other MACRO instructions within a MACRO definition: 

define load 2 z, one, two 

load z, one 
load z+1 , two 
terminate 

The use of this 

load 2 g, 4, 20 

will cause the following instruction to be assembled 

lac (4 
dac g 
lac (20 
dac g+1 

This operation will be performed many times. The argument A will be cycle 
lac 9 times and that can be used as part of the later work. For example, this 
is essentially the MACRO feature. 

A good, brief description of MACRO appeared in the May 1962 issue of 
DECUSCOPE. 

Thank you. 

In programs written in a large interpretive system (for example, a system for 
floating point computation), the interpreted instructions may be given names 
with mnemonic significance by parameter assignments or macro-instruction 
definitions. With macro-instructions, specifying the parameters of an inter- 
preted instruction is far more convenient. Of course, an interpreted instruction 
may occupy two or three registers, depending on how many arguments must be 
specified to the interpreter. This makes no difference when you are using 
macro-instructions. The macro-instruction may have a length of 1, 2, or 3 
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registers depending on the particular instruction it represents . 

Editor's Note: There was a comment from the floor about the ease of writing macros. 

Mr. Fredkin: There is one thing about macros. They are easy to write, but I would rather 

work with "instruction generators" which are easy to use. You use things more 
often than you write them and since you are only going to write it once you 
don't need MACRO to do it. Let me give you an example of this. What do 
you do when you want 39 in register? In DECAL you write: 39=>A but in 
MACRO you have to remember whether it is; LOAD A, 39 or: LOAD 39, A 
(which goes into which). I guess Dit made a mistake in the definition and you 
can write into A, put 39. His results will involve the equivalent law 47, and 
dac into A. Taking Dit Morse's example in the May DECUSCOPE; I showed 
him a program in DECAL which did the same thing and it was easily 1/8 as long 
and he said that's not fair because I used existing subroutines. I didn't use 
anything but a single DECAL library tape. So the program was shorter and 
much easier to write . 



Mr. Morse; 



Editor's Note: 
Dr. Hayes: 

Questions from 
the floor: 

Prof. Dennis: 

Mr. Saunders: 

Mr. Strollo: 

Mr. Morse: 
Dr. Hayes: 
Question: 
Dr. Hayes: 



This is true, but first of all, the example was to illustrate the use of macro- 
instructions and was not intended to compare MACRO'S virtues with those of 
any other programming system. However, let's use it for that as Ed has, and 
compare the effort needed to run the programs. Using MACRO, you need only 
do two passes on the symbolic tape and you have a binary tape which may be 
loaded and run. Using DECAL, you must first assemble the program, then load 
the linking loader, load the program, load the library tape, and if you do not 
wish to do this every time the program is run, you must load punch-off and 
punch out a binary tape . 

There was much reaction in the audience, especially from DECAL users. 

I think the audience is getting jittery because they cannot participate. Are 
there any questions from the audience? 

One of the features of DECAL is the instruction generator. I think this is 
equivalent to definitions. Is this correct? 

Yes, in the form of macro-instruction definitions. 

What you can do, for instance, is to have additional MACRO instructions 
written into the programs . What one cannot do is have the MACRO instructions 
written in duplicate on certain substructures depending on the value. 

If you can't get all of the instructions in on DECAL, you can insert a new tape 
in DECAL. Can you do this in MACRO? 

Yes, it is possible . 

Any comments from the floor? 

Not audible but Moderator repeated. 

The question has to do with the use of magnetic tape with DECAL. 



74 



Mr. Fredkin: When you use It, my experience with DECAL is that even paper tape tears 

much less. DECAL definitely has growth potential with respect to magnetic 
tape . 

(A question was directed to Mr. Fredkin about writing programs.) 

Mr. Fredkin: The thing is that DECAL has facility for doing things. In MACRO you write 

the programs over and over, but in DECAL we only do it once. Avery im- 
portant thing isthe joining of binary programs. You can doit in MACRO, but 
in DECAL we put them in locations and never bother with them again . In gen- 
eral, if you have a very complicated mathematical thing and you have to be 
fast, youcandopartsof it In DECAL algebraic language and then maybe convert. 

Prof. Dennis: The language I would use would depend on whether my program could be divided 

into subroutines. Certain programs are impossible to divide into subroutines. 
Then the question of MACRO versus DECAL depends on whether the macro- 
instruction feature of MACRO turns out to be useful with reference to what you 
are doing, and in most cases it is. The advantage of using MACRO for pro- 
grams with many subroutines Is that you can give nice names to their calling 
sequences and refer to them by convenient names. You have the advantage 
in DECAL which Is given by the linking loader feature . I prefer the coding 
format of MACRO to the coding format of DECAL. This, of course. Is some- 
thing outside of what either program can do for you and I admit that this Is a 
matter of opinion and my personal bias. It may also have something to do with 
my experience with MACRO . 

Editor's Nore: Discussion from the floor became more lively but speakers were heard by those 

sitting close by. A question was raised about the effect of DECAL on the PDP 
causing strain on input-output devices and It was pointed out that the M.I .T. ma- 
chine had been modified for MACRO and didn't accept DECAL. Jackson Wright 
repeated that the format of MACRO was easier for a program writer. A little 
excitement was engendered at this point. It was obvious that the audience was 
having a good time and that the DECAL users thought it more advantages for 
them in its present form . 

Dr. Hayes: Yes, Mr. Kotok. 

Mr. Kotok: I saw Ted Strollo working on a program on the flexowrlter. I didn't see any 

algebraic statements in it at all. He mentioned the manipulations which you 
will have to go through to type the DECAL program, some of which have to do 
with just which characters to choose. All the upper cases were troubling him. 
Also, a system where you have to put in Information as to where you are assepi- 
bllng and not compiling has many difficulties such as the difficulty of putting 
in addresses alone. 

Prof. Dennis: It depends on whether you are talking about compiling. If you are doing your 

own programming and have no typist, the more characters you have the more 
chance for errors . 

Mr. Strollo : This could be remedied by the action operators in DECAL. 

Mr. Fredkin: Ease of typing should not be the basis for evaluating a system. 
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Dr. Hayes: It is difficult to evaluate on the basis of how many keys you have to strike to 

make a comma . 

Mr. Fredkin: There was a time when I, too, used to program in MACRO. I liked MACRO 

instructions but I've made progress . The algebraic statement is the best although 
I'd like to have a combined system. 

Mr. Kotok: We ought to ask the audience what they like, we have been talking mainly 

about what we have to offer. It would be interesting to find out what they use 
and what they like. (Many voices and affirmative nods .) Who are DECAL 
users? 

Editor's Note: The moderator asked for a showof hands. The number of people using MACRO 

and the number of people using DECAL were about the same. The count for 
each system is given below. 

16 DECAL 

16 MACRO - (M.I.T. programmers) 
9 FRAP 

Dr. Hayes: About one-half of the audience did not indicate a preference. That is very 

interesting. Yes, Ed. 

Mr. Fredkin: MACRO is 5 years old and has reached some maturity. It has a good write-up. 

DECAL hasn't reached the same state of maturity but seems to be getting there. 
I think that within the not too distant future we will see DECAL with a good 
up-to-date Symbolic and a good write-up. 



Prof. Dennis; 



Dr. Hayes: 
Mr. Morse; 



Mr. Strollo; 



DECAL as it is presently offered, does not have the possibility of subscripted 
variables — the most important feature of the algebraic language. I understand 
a version of DECAL is being prepared now which does offer subscripts but I 
have the feeling that putting subscripts in DECAL is going to increase the in- 
efficiency of object programs over programs created with the absence of sub- 
scripts and I think it is possible to create a compiler language for a computer 
like the PDP-1 which could compile efficient object programs better than any 
today in that it would not be a one to one translation between source programs 
and object representations. I believe that such a program is possible and I 
would like to see one prepared and I would then be sure to use a compiler for 
any program I would write, but until such time I will use the assembler. 

Yes. Would the other members of the panel I ike to give some conclusions now? 

I believe MACRO is a better system for writing programs in which you need 
close control over the resulting object code and storage allocation, for example 
a real-time control program. In contrast, DECAL is more efficient from the 
point of view of the lapse time of beginning a program and getting it running. 

It's a matter of what type of program one is writing and whether it is desirable 
to use programs other people have worked out. When linking a groupof pro- 
grams together, one saves time with the DECAL system. 



Mr. Wright: 



Can you link programs with different symbols and different programs? 
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Mr. Fredkin: Yes.' DECAL does it.' BBN has it- In summary; an interesting thing happened 

some time ago - Elsa Newman got after me . (She's the greatest weapon DECUS 
has.') With reference to outlining virtues for DECAL or MACRO, her idea was 
to do something like this debate, but in written form for the DECUSCOPE. So 
Dit Morse and I got together to have a debate and what happened was that I 
agreed with nearly every statement he made and I think, vice versa. We got 
so bored with this, that after three-quarters of an hour, we went home. On 
the panel today, I decided that I would argue more strongly in behalf of DECAL, 
but my feeling is that both systems are good, for the reasons I've mentioned 
earlier. 

Mr. Kotok; I must agree with Ed. I argued for MACRO, but I feel as Ed does that both 

systems are worthwhile. I would have liked to find out about what others like. 
If one sees something that neither of these systems has or can find a compromise 
that you think is better drop a line to DECUSCOPE and we'll start something 
like the ACM debates. 

Audience: (laughed) 

Prof. Dennis: The discussion this afternoon served a very good purpose in bringing to light 

the features of these two systems to the audience. If this is so, it has served 
its purpose . 

Dr. Hayes: I hope, in spite of the good-fellowship and gemutlichkeit we have generated, 

that the audience will have gained some appreciation of the differences be- 
tween these two systems and that they will now be able to ask better questions 
about them for their own applications. 
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Section V 
APPENDIX 



ANNUAL MEETING 



Place: Air Force Cambridge Research Laboratories 
L. G. Hanscom Field 
Bedford, Massachusetts 



Date: October 10, 11, 1962 

PROGRAM 



October 10 -Wednesday 



0900 Registration 

0930 Introductory Remarks - Charlton M. Walter, President of DECUS 

0945 The PDP-4 Programming System - H. Morse, DEC 

1030 Reading Film with a Computer - M. Cappeiletti, Information International, Inc. 

1100 A World Oceanographic Data Display System - Edward Fredkin, Information 

International, Inc. 

1215 Lunch - Officers' Club 

1330 Minimax Detection Station Placement - Richard D. Smallwood, AFCRL 

1400 Displays - 

Group I: to the DX-1 Experimental Dynamic Processor Room 

Display of Minimax Detection Station Placement 

Dynamic Attribute Extraction Display & Discussion - Charlton M. Walter, 
AFCRL 

Display - Steven Bernstein, AFCRL 
Group II: to the Operations Applications Laboratory 

Displays & Discussion 

1600 Reconvene in Main Conference Room, Building 1105A - General Discussion 

and Security Check 

October 1 1 - Thursday 

0900 Matrix Package for the DX-1 System - Cannine Caso, Wolf R&D 

0920 Lawrence Radiation Laboratory's PDP-1 

1. A Peripheral Processor for Large Computers - Mrs. Dorothy Monk 

2. A PDP Systems Tape - Fraser Bonnell 

3. Translation Problems of a Peripheral Computer in a Multilingual House- 

R. P. Abbott and L. E. Mish 
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1100 Playing Music in Real Time - Peter R. Samson, MIT 

1115 Business, Introduction of Newly Elected Officers 

1962-63 Officers 

Edward Fredkin, President 
Elsa Newman, Secretary 

Committee Chairman 

Eunice Cronin, Meetings 
William Fletcher, Equipment 
John R. Hayes, Programming 
Elsa Newman, Publications 

1230 Lunch 

1330 The BBN Symbolic Version of DECAL - R. J. McQuillin, Bolt, Beranek & 

Newman, Inc. 

1530 DECAL, MACRO and the PDP-1 (Panel Discussion) 

Moderator John Hayes, OAL, Air Force Systems Command 

Panel Professor Jack Dennis, Massachusetts Institute of 

/r KAACQO) Technology 

Harrison Morse, Digital Equipment Corporation 
Alan Kotok, Massachusetts Institute of Technology 

(f nprAH Edward Fredkin, Information International, Inc. 

^tor UbCAg Theodore Strollo, AFCRL, BBN 

1730 Concluding Remarks 

Edward Fredkin, Decus President, (1962-1963) 
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ATTENDANCE 

ANNUAL MEETING 

October 10 and 11, 1962 

Air Force Cambridge Research Laboratories 



CHARLES W. ADAMS ASSOCIATES 
Bedford, Massachusetts 
John Gil more - D 
Mary Lanahan 
A I Rousseau 
Paul Rodenhiser 



AIR FORCE CAMBRIDGE RESEARCH LABS, 
Bedford, Massachusetts 
Frank Balzer, Jr. 
B. Bernstein - pd 
Harry Blum 
Roger E. Bove 
Eunice C. Cronin 
Robert Duncan 
Donald Easterday 
Stuart Gygi 
Edward LeFebvre 
Philip Lieberman 
John Mott-Smith 
Vera Pless 
Eugene Prange 

Richard D. Small wood P, pd 
Charlton M. Walter - P, D 
Weiant Wathen-Dunn - D 



AIR FORCE SYSTEMS COMMAND 
(Electronic System Division) 
Bedford, Massachusetts 

Charles R. Brown - pd, D 
Donald W. Connolly - pd 
James Duva 
Ira Goldstein 
John B. Goodenough 
John R. Hayes - P, D 
Sylvia Mayer 
Raymond Nickerson 
Anne Story 
Paul We in 
Robert Westfield 
Major John T. Willis 



ATOMIC ENERGY OF CANADA, LIMITED 
Chalk River, Canada 
J. Quarrington - D 

BIO-DYNAMICS 

Cambridge, Massachusetts 
Avery Johnson 

BOLT, BERANEK & NEWMAN, INC. 
Cambridge, Massachusetts 
Los Angeles, California 
M. Breen 
Lucy Darley 
Thomas Evans 
William Mann 
Thomas Marill - D 
Richard J. McQuillin - P 
David Park 
Theodore Strollo - pd 

JET PROPULSION LABORATORY 

(California Institute of Technology) 
Pasadena, California 
William Sholey 

DATA PROCESSING, INC. 
Waltham, Massachusetts 
Richard Mills - D 

DIGITAL EQUIPMENT CORPORATION 
Maynard, Massachusetts 
Harlan Anderson 
Robert Beckman 
Gordon Bell 
Peter Bonner 
Martin Graetz 
Benjamin Gurley 
John Koudela 
Nancy Lambert 
Harrison Morse - D 
Elsa Newman 
George Rice 
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GEOTECHNICAL INFORMATION 
Garland, Texas 

Gerald Clawson - D 

INFORMATION INTERNATIONAL, INC. 
Maynard, Massachusetts 

Michael Cappelletti - P 
Edward Fredkln - P, D 
John Wood 

INFORONICS, INC. 

Maynard, Massachusetts 

Lawrence Buckland - D 
William Nugent 

INFORMATION SYSTEMS DIVISION 

(International Telephone & Telegraph) 
Paramus, New Jersey 
H. Gould - D 



MASSACHUSETTS INSTITUTE OF TECHNOLOGY 
Cambridge, Massachusetts 

Professor Jack B. Dennis - P, D 
Alan Kotok 
Peter Samson - P 
Robert Saunders 
Jackson Wright 

MASSEY DICKENSEN COMPANY 
Waltham, Massachusetts 
W. J. Lennon 

OREGON PRIMATE RESEARCH CENTER 
Beaverton, Oregon 

Robert W. Coffin - D 

RAYTHEON COMPANY 

Way land, Massachusetts 
Ralph W. Zaorski 



ITEK CORPORATION 

Lexington, Massachusetts 
William Blotnick 
Charles Burgess 
Terrence R. Cullen 
Doris Gagnon 
Richard Hagan 
H. P. Peterson 
Earle Pughe 
Edward Radkowski 
Robert Rizzo 
Edward Spignise 
T. R. Stansfield 

LAWRENCE RADIATION LABORATORY 
Livermore, California 
Frazer Bonne 1 1 - D 
Lloyd Mish - P 
Dorothy T. Monk - P, D 



SYSTEMS RESEARCH LABORATORIES 
Dayton, Ohio 

W. Fahle - D 

UNITED AIRCRAFT RESEARCH LABORATORIES 
East Hartford, Connecticut 
Gerard A. Paquette - D 
David Sirota 

WOLF RESEARCH & DEVELOPMENT CORP. 
West Concord, Massachusetts 
D. B. Brzezenski - D 
Carmine Caso - P 
Norman Hirst 
Janet Seltzer 



Notes: D - DECUS Delegate or designated representative 
P - Speaker or Panel member, 
pd - Displayed CRT showing special programs. 
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